[Olsr-dev] OLSR on OLPC?

[Henning Rogge]

Am Mittwoch 04 Juni 2008 23:32:30 schrieb C. Scott Ananian:
> 802.11s saves power because it is implemented in the firmware of our
> wireless device.  Thus, we can turn off the CPU and still route
> packets, which saves power.  Since olsrd would run on the main CPU, we
> won't be able to route packets w/o keeping the CPU powered on.
The question is, does it work this way (and how much RAM does the wlan chip 
has for it's routing table) ? The 802.11s implementation for linux is done in 
software on the main CPU for example.

> We're very interested in testing this case (see response to Hannes below).
We would be happe to hear about your results and discuss sollutions for this 
problem. :)

> > We don't do this. Yes, this can be a problem...
>
> The Nortel guys think that prioritizing control traffic is very
> important (see below).  We'd be interested in doing more work here,
> especially w/r/t monitoring the routing tables to see if instability
> is a problem in practice.
I saw Hannes and me replied a little bit contradicting.

Routing traffic and normal traffic share the same transmission system (Layer 2 
data frames), so the control traffic is not really priorized (there were some 
experiments with 802.11s QoS priorizations I think, but I'm not sure).

The routing itself is done in kernel. Our olsr daemon sets a routing table, 
but never has to handle data packages itself.

> A good introduction to 802.11s routing is at:
>   http://doi.acm.org/10.1145/1234161.1234166
> which explicitly discusses the possibility of OLSR routing extensions.

> These seem to have been dropped in favor of a more general extension
> mechanism in the latest version of the 802.11s routing spec, which is
> at:
>  
> https://mentor.ieee.org/802.11/file/06/11-06-1778-01-000s-hwmp-specificatio
>n.doc
I just looked through the "proactive routing" parts... looks like a reactive 
routing protocoll with a "ask for routes proactively" addon. Doesn't look 
very efficient in my oppinion. But I will need some time to read it 
completely.

> To quote a Nortel engineer:
>   "When traffic affects routing you have a feed-back system which is
> not good. This is something we work very hard to avoid with wireline
> routing systems and its one of the reasons we almost never do
> congestion based shortest path routing. I.e. it would oscilate like
> crazy. [...] Its not hard to see that if traffic interferes with
> routing that in turn affects traffic and hence routing etc... and you
> get a horrible set of feedback oscillations in the network. I've seen
> this many times in routing systems where the control packets are not
> properly isolated from the data packets. The
> symptoms are usually the same (a mess) and the cure is the same
> (proper isolation/prioritization of control over data at every stage
> of handling). Early OSPF networks used to have this problem (hellos
> dropped due to congestion) and were quite spectacular and horrifying
> to watch melt down. More than one very expensive outage (i.e. entire
> countries) happened as a result."
At the moment we are using an ETX metric. Each node sends a Hello package at a 
regular interval and calculates an average of the number of received Hello 
packets (compared to the total number). The resulting value is distributed 
globally and is used for routing.

> It's my understanding that a number of different 802.11 chipset
> vendors have implemented some form of extended media access protocol
> for 802.11; I'm curious to know whether that's part of the secret
> sauce folks like those in Berlin need to use in order to make 802.11
> (mesh or not) work in large settings.
Even large Freifunk networks (like Berlin or Vienna) use normal 802.11 I 
think. At least they don't use anything chipset specific (because there is no 
homogenous hardware platform).

Henning


*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)