DART Dynamic Address RouTing A network layer routing protocol, Jakob Eriksson, Michalis Faloutsos and Srikanth Krishnamurthy Department of Computer Science.

DARTDARTDynamic Address RouTing

A network layer routing protocol,Jakob Eriksson, Michalis Faloutsos and

Srikanth KrishnamurthyDepartment of Computer Science and

Engineering

Dynamic Address RouTing

A network layer routing protocol,Jakob Eriksson, Michalis Faloutsos and

Srikanth KrishnamurthyDepartment of Computer Science and

Engineering

•Routing in networks of millions of strangers.

•Be able to route packets even through handheld, low power, devices.

•Support wires, as well as directional and omnidirectional antennae.

•No central ownership / administration.

•Plug-n-play operation, zero-configuration.

•Routing in networks of millions of strangers.

•Be able to route packets even through handheld, low power, devices.

•Support wires, as well as directional and omnidirectional antennae.

•No central ownership / administration.

•Plug-n-play operation, zero-configuration.

The ProblemThe Problem

•Replace node address with two numbers:

•Node identifier - static.

•Routing address - dynamic.

•Dynamic routing address indicates current location in network topology.

•Distributed lookup table maps identifier to current routing address.

•Replace node address with two numbers:

•Node identifier - static.

•Routing address - dynamic.

•Dynamic routing address indicates current location in network topology.

•Distributed lookup table maps identifier to current routing address.

DART basicsDART basics

Why on Earth...?Why on Earth...?

Rural networksRural networks

Consumer owned networking

Consumer owned networking

Theater-wide military networksTheater-wide military networks

Internet 2.0?Internet 2.0?

Civil disobedienceCivil disobedience

Protecting civil libertiesProtecting civil liberties

Free speechFree speech

Ubiquitous and free connectivity?Ubiquitous and free connectivity?

Networked societyNetworked society

Who knew what Internet would become?

Who knew what Internet would become?

Circumventing copyrights?Circumventing copyrights?Because we can!Because we can!

Developing countriesDeveloping countries

•Related work

•DART

•Address allocation

•Routing

•Node Lookup

•Simulations

•Future work

•Conclusion

•Related work

•DART

•Address allocation

•Routing

•Node Lookup

•Simulations

•Future work

•Conclusion

RoadmapRoadmap

•Hierarchical routing (Kleinrock, Kamoun ‘77)

•Flat ad hoc routing protocols: AODV, DSR, DSDV. Numerous derivatives.

•Clustering based routing: Landmark, LANMAR, Clusterhead, Hierarchical State Routing, MMWN, etc.

•Georouting: LAR, DREAM, Grid, etc.

•Distributed Hashtables: Chord, Plaxton routing etc.

•Hierarchical routing (Kleinrock, Kamoun ‘77)

•Flat ad hoc routing protocols: AODV, DSR, DSDV. Numerous derivatives.

•Clustering based routing: Landmark, LANMAR, Clusterhead, Hierarchical State Routing, MMWN, etc.

•Georouting: LAR, DREAM, Grid, etc.

•Distributed Hashtables: Chord, Plaxton routing etc.

Related WorkRelated Work

•Routing address - a fixed length binary string.

•Address Prefix - a sequence of bits taken from the most significant end of a routing address.

•Prefix Subgraph - The graph induced from a network graph by the set of nodes with a given prefix.

•Routing address - a fixed length binary string.

•Address Prefix - a sequence of bits taken from the most significant end of a routing address.

•Prefix Subgraph - The graph induced from a network graph by the set of nodes with a given prefix.

Some TerminologySome Terminology

Address Space as Binary Tree

Address Space as Binary Tree

•Routing addresses form a virtual binary tree.

•All nodes within any given subtree are able to communicate using only nodes in that subtree.

•Routing addresses form a virtual binary tree.

•All nodes within any given subtree are able to communicate using only nodes in that subtree.

•Dynamically maintain a unique address for every node.

•Ensure that all prefix subgraphs are connected.

•Minimize communication overhead and require no centralized resources/infrastructure.

•Minimize required address size (in bits).

•Dynamically maintain a unique address for every node.

•Ensure that all prefix subgraphs are connected.

•Minimize communication overhead and require no centralized resources/infrastructure.

•Minimize required address size (in bits).

The Addressing ProblemThe Addressing Problem

• Joining node picks an address with a prefix common with one of its neighbors.

•The routing table is consulted to ensure that each prefix only induces a single, connected, network subgraph.

•To minimize address size, shorter prefixes are preferred.

•When changing address, a smaller change is preferred, to improve stability.

• Joining node picks an address with a prefix common with one of its neighbors.

•The routing table is consulted to ensure that each prefix only induces a single, connected, network subgraph.

•To minimize address size, shorter prefixes are preferred.

•When changing address, a smaller change is preferred, to improve stability.

Basic SolutionBasic Solution

Address Allocation example

Address Allocation example

When a node joins, it picks an address that shares a prefix one of its neighbors.

When a node joins, it picks an address that shares a prefix one of its neighbors.

•Thanks to the invariant, routing is scalable.

•Each node keeps log N routing entries.

•Thanks to the invariant, routing is scalable.

•Each node keeps log N routing entries.

The Routing TableThe Routing Table

Node Lookup TableNode Lookup Table• Efficient distributed hashtable (DHT) that

maps Node ID -> Routing Address.

• Similar to overlay DHT research, but uses existing routing layer state for efficiency.

• Nodes periodically send their current address to one other node, their lookup peer.

• Upon connection establishment, the routing address of the destination retrieved from the destination’s lookup peer.

• Efficient distributed hashtable (DHT) that maps Node ID -> Routing Address.

• Similar to overlay DHT research, but uses existing routing layer state for efficiency.

• Nodes periodically send their current address to one other node, their lookup peer.

• Upon connection establishment, the routing address of the destination retrieved from the destination’s lookup peer.

Lookup Table BasicsLookup Table Basics

Node 3 (011)Node 3 (011)

“Node 3 has address 001”“Node 3 has address 001”

Node 7 (111)Node 7 (111)

“Node 7 has address 000”“Node 7 has address 000”

????

Every ID->Address mapping is stored at the node whose address most closely matches the

ID!

Every ID->Address mapping is stored at the node whose address most closely matches the

ID!

•Two nodes may select the same address prefix independently, possibly yielding a disconnected prefix subgraph.

•Similarly, a single prefix subgraph may be partitioned due to link failure.

•How do we detect the problem and determine who gets to keep their address(es)?

•Two nodes may select the same address prefix independently, possibly yielding a disconnected prefix subgraph.

•Similarly, a single prefix subgraph may be partitioned due to link failure.

•How do we detect the problem and determine who gets to keep their address(es)?

Prefix Conflict ResolutionPrefix Conflict Resolution

•For every routing entry, keep track of the minimum Node ID within that prefix subgraph.

• If two routes are discovered to the same prefix, but with different minimum Node IDs, discard the one with the higher ID.

• If a node receives a route to its own prefix, but with a lower ID, it immediately computes a new, valid address.

•For every routing entry, keep track of the minimum Node ID within that prefix subgraph.

• If two routes are discovered to the same prefix, but with different minimum Node IDs, discard the one with the higher ID.

• If a node receives a route to its own prefix, but with a lower ID, it immediately computes a new, valid address.

Solution: Use Node IDsSolution: Use Node IDs

•Performed using two simulators:

•Home-grown for speed and scalability.

•ns-2 for comparisons and accuracy.

•Wireless nodes, with omnidirectional antennae.

•Performed using two simulators:

•Home-grown for speed and scalability.

•ns-2 for comparisons and accuracy.

•Wireless nodes, with omnidirectional antennae.

SimulationsSimulations

Extremely small average routing table size < 2*log N.

About 15 entries for 4000 nodes!

Extremely small average routing table size < 2*log N.

About 15 entries for 4000 nodes!

Routing Table SizeRouting Table Size

0

10

20

30

10 100 1000 10000

Network Size (nodes)

Ro

uti

ng

Tab

le S

ize

(e

ntr

ies)

•Low average path stretch, 30-35%, so route aggregation is not hurting us much.

•Low average path stretch, 30-35%, so route aggregation is not hurting us much.

Experimental ResultsExperimental Results

0

0.1

0.2

0.3

0.4

0.5

0.6

125 250 375 500 625 750 875 1000

Network Size (nodes)

Path

Str

etc

h (

fracti

onal in

cre

ase)

•Ns-2 doesn’t scale to large wireless simulations.

•Simulated 400-node networks.

•Varied connection establishment frequency (CEF).

•Arguably, CEF increases in larger networks.

•Also, CEF depends on traffic patterns.

•Ns-2 doesn’t scale to large wireless simulations.

•Simulated 400-node networks.

•Varied connection establishment frequency (CEF).

•Arguably, CEF increases in larger networks.

•Also, CEF depends on traffic patterns.

Simulating large networks

Simulating large networks

Overhead vs. CEFOverhead vs. CEF

• DART overhead is not affected by CEF.

• Reactive protocols suffer when CEF increases.

• DART overhead is not affected by CEF.

• Reactive protocols suffer when CEF increases.

0

2000

4000

6000

8000

10000

12000

0.1 1 10 100

Connection Establishment Frequency (conn/s)

Ove

rhe

ad

(p

acke

ts/s

)

Throughput vs. CEFThroughput vs. CEF

• DART reliably outperforms AODV/DSR when connection establishment frequency > 3.

• CEF == 3 means one connection/node every 2 mins.

• DART reliably outperforms AODV/DSR when connection establishment frequency > 3.

• CEF == 3 means one connection/node every 2 mins.

0

5

10

15

20

25

30

0.1 1 10 100

Connection Establishment Frequency (conn/s)

Thro

ughput

(packets

/s)

•Finalize addressing, routing and lookup

•Sabotage resistance

•Fairness and incentive mechanism to encourage sharing

•Linux kernel implementation

•Finalize addressing, routing and lookup

•Sabotage resistance

•Fairness and incentive mechanism to encourage sharing

•Linux kernel implementation

Future WorkFuture Work

•Addressing still needs more work to get improved clustering of nodes.

•Routing still suffers from route instability, a’la Distance Vector protocols.

•Lookup service should support multiple levels for larger networks, for better scalability.

•Addressing still needs more work to get improved clustering of nodes.

•Routing still suffers from route instability, a’la Distance Vector protocols.

•Lookup service should support multiple levels for larger networks, for better scalability.

Finalize things...Finalize things...

•Any large, open network will have a non-zero number of malicious nodes.

•Currently, a single node could cause significant damage to the network.

•Goal: to minimize the damage a small fraction of malicious nodes can cause.

•Plan: use all routes, and load balance away from those that do not perform.

•Any large, open network will have a non-zero number of malicious nodes.

•Currently, a single node could cause significant damage to the network.

•Goal: to minimize the damage a small fraction of malicious nodes can cause.

•Plan: use all routes, and load balance away from those that do not perform.

Sabotage ResistanceSabotage Resistance

• In a collaborative system, things must be fair, or people won’t participate. This is crucial!

•You get back as much as you contribute to the whole? What about edge nodes? Weighted location dependent fairness ?

•How? but probably has to be on a next-hop basis.

• In a collaborative system, things must be fair, or people won’t participate. This is crucial!

•You get back as much as you contribute to the whole? What about edge nodes? Weighted location dependent fairness ?

•How? but probably has to be on a next-hop basis.

Routing Layer FairnessRouting Layer Fairness

•What: Make DART useful for general purpose wireless and wired networking today.

•Why: Why else are we doing this?

•How: Initially use IP address as identifier, put in a DART wedge between MAC and IP layer.

•Where: Linux kernel, potentially OS X and Palm OS if their models allow it.

•What: Make DART useful for general purpose wireless and wired networking today.

•Why: Why else are we doing this?

•How: Initially use IP address as identifier, put in a DART wedge between MAC and IP layer.

•Where: Linux kernel, potentially OS X and Palm OS if their models allow it.

Real-world implementation

Real-world implementation

•Position paper at IPTPS’03.

•Poster at ICNP’03, lots of interest!

•Paper accepted to INFOCOM’04.

•Established presence in research community, a lot of people know about DART already!

•Position paper at IPTPS’03.

•Poster at ICNP’03, lots of interest!

•Paper accepted to INFOCOM’04.

•Established presence in research community, a lot of people know about DART already!

Academic Accomplishments

Academic Accomplishments

•DART is a scalable alternative to current ad hoc routing protocols.

•Changing “address” to “ID + routing address” can result in increased scalability.

•Simulation results indicate significant performance improvement even for 400-node networks.

•There’s some left to do !

•DART is a scalable alternative to current ad hoc routing protocols.

•Changing “address” to “ID + routing address” can result in increased scalability.

•Simulation results indicate significant performance improvement even for 400-node networks.

•There’s some left to do !

ConclusionsConclusions

Application Layer Multicast Algorithm

A Multicast Protocol for Ad Hoc Networks,

Min Ge, Michalis Faloutsos and Srikanth Krishnamurthy

Department of Computer Science and Engineering

Application Layer Multicast Algorithm

A Multicast Protocol for Ad Hoc Networks,

Min Ge, Michalis Faloutsos and Srikanth Krishnamurthy

Department of Computer Science and Engineering

ALMAALMA

• Multicast Structure need not be reconfigured upon each link failure.

• Reliability, Congestion Control and Flow Control -- thanks to transport layer solutions.

• Independent of routing.

• Ease of Security.

• Multicast Structure need not be reconfigured upon each link failure.

• Reliability, Congestion Control and Flow Control -- thanks to transport layer solutions.

• Independent of routing.

• Ease of Security.

Why Application Layer?Why Application Layer?

• Use of application layer schemes do not exploit broadcast nature of the wireless medium.

• Degradation of performance under heavy loads -- much more traffic than network layer solutions.

• Use of application layer schemes do not exploit broadcast nature of the wireless medium.

• Degradation of performance under heavy loads -- much more traffic than network layer solutions.

Why not Application Layer ?

Why not Application Layer ?

• Evaluate benefits and examine trade-offs of application layer multicast.

• Design a simple yet efficient application layer multicast protocol -- ALMA

• Compare with IP layer multicast competition -- ODMRP.

• Find regimes (if any) wherein application layer protocol is beneficial in terms of performance.

• Evaluate benefits and examine trade-offs of application layer multicast.

• Design a simple yet efficient application layer multicast protocol -- ALMA

• Compare with IP layer multicast competition -- ODMRP.

• Find regimes (if any) wherein application layer protocol is beneficial in terms of performance.

Objectives and StrategyObjectives and Strategy

• Construct an application layer multicast tree.

• Scheme similar to Narada -- Overlay Multicast protocol designed for the Internet.

• Single source -- nodes join based on advertisements.

• Assumption : There exists a rendezvous point that supplies a list of group members.

• Construct an application layer multicast tree.

• Scheme similar to Narada -- Overlay Multicast protocol designed for the Internet.

• Single source -- nodes join based on advertisements.

• Assumption : There exists a rendezvous point that supplies a list of group members.

ALMAALMA

The ALMA Tree EvolvesThe ALMA Tree Evolves

•A node sends a “Hello” message to its parent and measures the RTT periodically

•Search for a new parent within a pre-specified range if RTT is large.

•If RTT < threshold1 stay with the current parent

•If threshold1<RTT<threshold2, search in one hop range

•If threshold2<RTT<threshold3, search in two hop range

•A node sends a “Hello” message to its parent and measures the RTT periodically

•Search for a new parent within a pre-specified range if RTT is large.

•If RTT < threshold1 stay with the current parent

•If threshold1<RTT<threshold2, search in one hop range

•If threshold2<RTT<threshold3, search in two hop range

Self-configurationSelf-configuration

S

E

A

B

D

F

G

C

C

S

E

A

B

D

F

G

C

B

S

E

A

D

F

G

Overlay Tree Search one virtual hop Search three virtual hops

Avoiding loops in ALMAAvoiding loops in ALMA

• Each member maintains the path to the root

• ALMA precludes a member from becoming the child of of one of its descendants

• Each member checks its path to the root periodically. If a loop is detected, the member will disconnect from its parent and rejoin the group.

• Each member maintains the path to the root

• ALMA precludes a member from becoming the child of of one of its descendants

• Each member checks its path to the root periodically. If a loop is detected, the member will disconnect from its parent and rejoin the group.

Other DetailsOther Details• Reliability

• Each member caches the packets it forwarded recently

• When a node switches, it requests the new parent for the packets that it has yet to receive.

• If the new parent is able to provide the packets, it relinquishes the old connection; else continues to receive packets from the old parent until it catches up with new parent.

• Node failure

• If a node does not receive any message (including a response to its Hello Message) from its parent for a long time, it rejoins the group.

• Reliability

• Each member caches the packets it forwarded recently

• When a node switches, it requests the new parent for the packets that it has yet to receive.

• If the new parent is able to provide the packets, it relinquishes the old connection; else continues to receive packets from the old parent until it catches up with new parent.

• Node failure

• If a node does not receive any message (including a response to its Hello Message) from its parent for a long time, it rejoins the group.

Simulation ModelSimulation Model• Simulator : GloMoSim 2.03

• Topology: 120 nodes in 1000m * 1000m, ; some nodes are fixed and arranged in a grid to avoid the network partition, other nodes are mobile.

• Radio Propagation Range: 120 m

• Channel Capacity: 2 Mb/sec

• Mobility Pattern: random-way-point model.

• IEEE 802.11 MAC with Distributed Coordination function (DCF).

• Routing Protocol: AODV.

• Member nodes join the multicast session at the beginning of the simulation and remain as members.

• Simulator : GloMoSim 2.03

• Topology: 120 nodes in 1000m * 1000m, ; some nodes are fixed and arranged in a grid to avoid the network partition, other nodes are mobile.

• Radio Propagation Range: 120 m

• Channel Capacity: 2 Mb/sec

• Mobility Pattern: random-way-point model.

• IEEE 802.11 MAC with Distributed Coordination function (DCF).

• Routing Protocol: AODV.

• Member nodes join the multicast session at the beginning of the simulation and remain as members.

MetricsMetrics

• Packet Delivery Ratio

• the ratio of the number of packets delivered to the receivers to the number of data packets sent.

• Goodput

• The fraction of time that useful information is received.

• Packet Delivery Ratio

• the ratio of the number of packets delivered to the receivers to the number of data packets sent.

• Goodput

• The fraction of time that useful information is received.

Other ProtocolsOther Protocols

•Progressively Adapted Sub-Tree in Dynamic Mesh (PAST –DM) – Prior Application Layer Multicast Protocol (by Gui and Mohapatra, WCNC 03) – performs the best among existing application layer multicast schemes.

•On Demand Multicast Routing Protocol (ODMRP) – IP Layer Routing by S.J.Lee et al.

•Progressively Adapted Sub-Tree in Dynamic Mesh (PAST –DM) – Prior Application Layer Multicast Protocol (by Gui and Mohapatra, WCNC 03) – performs the best among existing application layer multicast schemes.

•On Demand Multicast Routing Protocol (ODMRP) – IP Layer Routing by S.J.Lee et al.

PAST-DMPAST-DM

•Link-State Information Exchanged – Each node has entire topology information.

•Construct Source Based Steiner Tree

•Periodically Refresh Tree

•Source is responsible for construction/ maintenance of tree.

•Link-State Information Exchanged – Each node has entire topology information.

•Construct Source Based Steiner Tree

•Periodically Refresh Tree

•Source is responsible for construction/ maintenance of tree.

ODMRPODMRP

• Construction of a mesh – called forwarding group.

• Data forwarded on shortest path on mesh.

• Sources establish and maintain tree on-demand.

• Sources broadcast Join Queries – Receivers respond by broadcasting Join Tables.

• Join Tables are relayed back to the source.

• The path is thus established between a source and a receiver.

• Construction of a mesh – called forwarding group.

• Data forwarded on shortest path on mesh.

• Sources establish and maintain tree on-demand.

• Sources broadcast Join Queries – Receivers respond by broadcasting Join Tables.

• Join Tables are relayed back to the source.

• The path is thus established between a source and a receiver.

Sample ResultsSample Results

• ALMA provides lower cost, lower stress than PAST-DM

• Local adaptability and reconfiguration help.

Comparisons with ODMRP

Comparisons with ODMRP

• ALMA better for smaller groups

• ODMRP better for larger groups.

• ALMA suffers when group size increases – a large number of redundant transmissions.

To ConcludeTo Conclude

•Application Layer Multicasting is a viable promising approach for small multicast groups.

• Note that we have only looked at performance – other benefits include reliability, security, flow control and congestion control.

•Further studies needed to fine tune ALMA.

•Application Layer Multicasting is a viable promising approach for small multicast groups.

• Note that we have only looked at performance – other benefits include reliability, security, flow control and congestion control.

•Further studies needed to fine tune ALMA.

Thank you.Thank you.