Ad Hoc Networking

1. Ad Hoc Networking Tom Roeder CS415 2005sp

2. Part IV questions?

3. 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

4. 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

5. 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)

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. AODV route requests A B • 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 C

14. 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

15. 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

16. AODV example RREQ RREQ A RREQ RREQ RREQ RREQ RREQ B RREQ RREQ RREQ RREP RREQ RREQ RREQ RREQ RREP RREP ! C

17. 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

18. 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

19. 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

20. 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.

21. 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

22. 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

23. 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

24. 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