[Olsr-dev] OLSR on OLPC?

Henning Rogge (spam-protected)
Thu Jun 5 14:34:02 CEST 2008

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

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


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 

More information about the Olsr-dev mailing list