[Olsr-dev] OLSR on OLPC?
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
> > 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:
> 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
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
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
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