[Olsr-dev] olsrd without link sensing

Giovanni Di Stasi (spam-protected)
Mon Jun 23 19:34:24 CEST 2008


Il Monday 23 June 2008 19:16:33 Henning Rogge ha scritto:
> On Mon, Jun 23, 2008 at 18:40, Giovanni Di Stasi <(spam-protected)> wrote:
> > Hi again.
> > what I'd like to do is expressed well by the following passage of the rfc
> > 3626:
> >
> > "If sufficient information is provided by the link-layer, this
> > may be utilized to populate the local link set instead of HELLO
> > message exchange."
>
> Theoretically you can run OLSR completely on layer 2 (with MACs
> instead of IP addresses).
>

Yes, but I suppose that that wouldn't be an easy change, would it?

> > I've studied a bit the sources of olsrd, and this is what I got so far:
> >
> > I could, from inside my plugin:
> >
> > call olsr_stop_timer(ifp->hello_gen_timer) on my interface (there is just
> > one interface in my case) to stop the hello generation.
>
> ok.
>
> > register a recursive event that, when triggered:
>
> recursive event ?
>

an event that is triggered on a regular basis (every X seconds); 
The pluginn registeres the event in this way:

olsr_register_scheduler_event(olsr_events, NULL, 8, 1, NULL);

> >        gets the information on the links from the layer 2 module;
> >
> >        for every link to add:
> >
> >                creates the link_entry structure; sets the addresses
> > (local interface, remote interface and remote interface main address) and
> > the local_if;
> >
> >                adds the link with list_add_before
> >
> >                set linkcost  to 1;
>
> Not good... you would loose the advantage of the LQ implementation (ETX).

Yes, but this is because our routing algorithm just needs to know the 
distances in terms of hops.

>
> >                set the neighbor (the endpoint of the link) as mpr
> > (setting is_mpr and was_mpr to true);
> >
> >        for every link to remove:
> >
> >                find the link
> >
> >                calls olsr_expire_link_entry on that link
> >
> > Olsrd would be configured to use lq for measuring the link quality; the
> > TC redundancy would be set to
>
> LQs are measured by adding fields to the Hello packages... so this
> might be a little bit more complicated.
>
Maybe I should use LinkQualityLevel 0; I made a mistake, there no reason to 
use LinkQualityLevel 2.

> > Is it gonna work?
> >
> > You mentioned the fact that olsrd is not thread safe. Does that
> > constitute a problem when I do the aforementioned actions from inside a
> > plugin event?
>
> Depends on how your plugin is triggered.
>
The plugin is triggered every once in a while (as I said above).

> If you run in the olsrd main-thread, you have to go back to the main
> scheduler regularly.
>

I would like to avoid modifying the source code of olsrd (that's why I'm 
thinking of a plugin).


-- 
Giovanni Di Stasi, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio, 21 - 80125 Napoli - Italy

Phone:    +39 081 7683821
Fax:      +39 081 7683816
E-mail:   (spam-protected)




More information about the Olsr-dev mailing list