AODV OLSR Notes
From 410 Resources
Contents |
AODV (Jorge)
Constant size routing messages, addresses: 48 bytes inside IP. Maybe less with 6lowpan. Destination sequence number - may be invalid
RREP seqno = max(it's seq no, the seq no in the RREQ)
Will hear one RREP from nodes with greater seqnos, unless bit is set. Then you get one from just the dest.
RERR contact everyone in precursor list who are effected by link failure. each precursor then contacts its precursors, down the tree. NOT just one-hop neighbors. Philosophically, do we want to flood the network on a broken link? There are cases when we might not want to propagate the RERR, for instance if we have another path.
Lack of MUST, SHOULD, etc.
Destination replies to (one | all) of RREQs it gets. Could it wait to receive
a few and just send one back?
Neighbor table: has previous hop, source, destination. Could it also have more state? IE a few more nodes along the path.
AODV-P: AODV + data message broadcast. NOT in the RFC. TODO: Workload Overhead: put on wiki with explanation for each numbers.
Many timers, many of which result in RERRs.
- Some optional messages result in rate-limiting of RERRs, which could result in very large queues.
- If Communication rate is less then churn interval, every time I try to communicate I disassemble the tree (did I get that right? --SDH).
When we say what's wrong with AODV, others will comment and check out math. Look at traces from other networks to limit specificity of analysis. Defining the metric is also useful to allow others to compare on different networks.
Interesting coefficients: (use interval) (churn interval) s d h D
OLSR (Jay)
Parameters: N d
On a wireless network, are neighbors on multiple interfaces? 1-hop and 2-hop neighbors. Three different sets transmitted via HELLO: TC, Link State, MPRs. Lots of redundancy.
Everybody ends up building paths to every destination through cluster heads/MPRs, with last hop.
All nodes maintain the cluster set despite only requiring the MPRs to keep it. Topology set has (link state | paths per destination)?
The size of a TC message is d: adjacent links.
Scaling: routing table recalculated with any churn. Generate analysis with time as a parameter: churn period
What happens when the density is high? Then the compression may work better.
The savings is just in the number of messages, not the state.
Discussion / Planning
Hydrowatch people next week, Th @ 1. Therefore next meeting 10/25 @ 11:30.
For next meeting, discuss
- LQSR Link quality state routing?
- CTP/LQI?
- DYMO?
- RIP?
- OSPF?
- TBRPF?
At least DYMO next week: Arsalan will present, Jorge will get lunch.
Terminology
- [total nodes/extent/N]
- [degree/density/d]
- [number hops/diameter/width]
- [number sources/S]
- [number destinations/D]
- [logical workload/(non-routing) message interarrival time]
- [churn/link interarrival time/entropy rate].
Random waypoint models only consider churn implicitly; this is a good metric. TODO: compute expected churn as a function of random waypoint model parameters. (SDH & Jorge will work on this).
scribe: SDH
