Ad Hoc Networking
Tom Roeder
CS415 2005sp
Part IV questions?
What is an ad hoc network?

Nodes discover and maintain routes




no use of infrastructure
Every host is also a router
(thus not all routers are trusted…)
Can be done over the infrastructure
Features of an ad hoc network

Change in reachability



Often power constrained



over time as nodes die and come back
over space as nodes move
The screen is the constraint on your laptops, but
on many smaller machines, it is the network
Oft cited: 1 packet for 3000 instructions
It adapts!

Must not rely on static configurations
Applications

Sensor networks

little, power-constrained “motes”





attached to animals in a park
scattered on the ground from the air (military)
Rescue workers in a disaster area
Educational apps (www.silicon-chalk.com)
Operating systems

MagnetOS (Mobisys ’05)
(www.cs.cornell.edu/people/egs/magnetos)
Overlays


leads in to P2P systems
Why bother?







route around problems
build multicast trees
illegally share files
gain anonymity
build trust networks
optimize RSS feeds
If this interests you, check out Copano
Types of ad hoc routing

Proactive


Reactive


DSR, AODV
Hybrid


DSDV, Link-state variants
ZRP, HARP, SHARP
Overlay

We’re not going to discuss this more
Costs and benefits: proactive

Pushes information





low message latency
high state overhead
high message overhead
OK when network is small
Full link state grows as n2


Can seriously impact throughput
Not good for high mobility
Costs and benefits: reactive

Generates route at send time

high initial latency



no wasted route information
can lead to broadcast storms


brings the network down even faster at the end
Good for reasonably high mobility


caching helps tremendously
too fast and there’s nothing we can do
Widely used
802.11b MAC layer

To send a packet, must reserve the medium


Additional optional protocol for 802.11b is





Uses a CSMA protocol
RTS (Ready To Send)
CTS (Clear To Send)
Data
ACK
Hidden terminal problem

may get lower throughput than expected
Distance Vector protocols

Key Distance Vector idea:






Instead of storing the full path, just keep direction
“If I want to get to A, my next hop is B”
Trade DV information with neighbors via flooding
Based on distributed Bellman-Ford algorithm
Can suffer from loops and counting-to-infinity
AODV finds distance vectors reactively


Based on DSDV, which does it proactively
Uses a sequence number to try to avoid problems
AODV information per node

A table (cache) of known distance vectors


refresh rate will controll the message overhead
<seqnum, dest, hop, hopcount>

seqnum: incremented on new information



dest: the identifier of the destination



used to avoid counting to infinity.
Remember the last known seqnum for each cache elt
note that identifiers are arbitrary
hop: the identifier of next hop to get to dest
hopcount: how many hops on this route
AODV route requests
A

Node A wants to send a packet to B




B
broadcasts a RREQ (with some TTL)
heard by B, B sends a reply
A sends directly to B
Node A wants to send a packet to C




broadcasts a RREQ
heard by B, but B just heard from C
Sends reply <1, C, B, 1>
A sends packet to B, who forwards it to C
C
AODV route replies

A node receiving a RREQ sends a route reply




from its cache if it has this route
else it forwards the RREQ
It also updates its path to the requestor with the
RREQ and TTL, if it is better
If a node hears a better route reply



it doesn’t send its own
it records the better route
this helps avoid broadcast storms in flooding
AODV route caches

Think of the route cache as an optimization



We could always choose to flood
This would just have high latency and broadcast
storms, but would still be correct (don’t do it!)
Timeout is critical


When a link goes down, the cache is wrong
We don’t do explicit invalidation


real AODV does
uses MAC link error info to guess at disconnection
AODV example
RREQ
RREQ
A
RREQ
RREQ
RREQ
RREQ
RREQ
B
RREQ
RREQ
RREP
RREQ
RREQ
RREP
RREQ
RREQ
RREQ
RREP
!
C
AODV details to ignore

Counting to infinity is possible but hard



Don’t worry about security
We are not managing the errors explicitly



see http://www.cse.ucsc.edu/research/
ccrg/publications/hari.icc.2005.pdf
This is clearly suboptimal, but easier
See the AODV and DSR papers if you’re
interested
Don’t worry if you get low throughput
AODV header spec

type (2 bits)


seqnum (4 bytes)




RREP, RREQ, DATA
incremented on new routes
from node (4 bytes)
destination node (4 bytes)
Time To Live (1 byte)

set to MAX_PATH_LENGTH
Layering and Abstraction

AODV is a layer below miniports



Other than AODV control packets,



it acts like IP for us
it should encapsulate the miniports code
all packets should be miniports or minisockets
we still are delivering to miniports on remote node
We have simply taken away the reliance on
the IP routing infrastructure
Testing: over the infrastructure

We provide a “broadcast” layer for your code

file format
saranac
heineken
dosequis
kingfisher
tecate
.xx.x
x.xx.
xx...
.x..x
x..x.
Testing: over the infrastructure

Use the network_broadcast_pkt




Use the network_send_pkt



To send to all reachable nodes
When you don’t know the direction: RREQ
For returning cached RREPs (optimization)
For returning RREPs
For data packets
You implement miniroute_send_pkt

Does AODV, then unicasts the packet
Testing: over the wireless

We do not have enough tablets to give you




You would need a large network to test this
We will do it in section
We will schedule a few other times
Can also use any 802.11b Windows device


laptop
desktop with wireless card
Broadcast storm

Issues with flooding wireless networks




May have already heard an answer, but unicast
May have a better answer than one you hear
n2 flooding is expensive to discover linear paths
What can we do?


Damping
Promiscuous unicast listening
Implementations and help

For real implementations, see



AODV: moment.cs.ucsb.edu/AODV/aodv.html
DSR: www.monarch.cs.cmu.edu/dsr-impl.html
To try out AODV without the hassle, see

sns: www.cs.cornell.edu/People/egs/sns/


simulated implementation of AODV
Papers

See the above sites for references or just google it