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 over time as nodes die and come back over space as nodes move
Often power constrained 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 DSDV, Link-state variants
Reactive DSR, AODV
Hybrid 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
caching helps tremendously no wasted route information can lead to broadcast storms
brings the network down even faster at the end
Good for reasonably high mobility too fast and there’s nothing we can do
Widely used
802.11b MAC layer
To send a packet, must reserve the medium Uses a CSMA protocol
Additional optional protocol for 802.11b is 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
used to avoid counting to infinity. Remember the last known seqnum for each cache elt
dest: the identifier of the destination 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
Node A wants to send a packet to 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
AB
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
A
B
C
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQRREQ
RREQ!RREP
RREP
RREP
AODV details to ignore
Counting to infinity is possible but hard see http://www.cse.ucsc.edu/research/
ccrg/publications/hari.icc.2005.pdf Don’t worry about security We are not managing the errors explicitly
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) RREP, RREQ, DATA
seqnum (4 bytes) 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 it acts like IP for us it should encapsulate the miniports code
Other than AODV control packets, 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 To send to all reachable nodes When you don’t know the direction: RREQ For returning cached RREPs (optimization)
Use the network_send_pkt 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