[Babel-users] Babel configuration with AP/STA mode.

[mason]

Hi,

First of all, thanks for your explanations.

On Wed, Sep 8, 2010 at 3:16 AM, Juliusz Chroboczek <
Juliusz.Chroboczek at pps.jussieu.fr> wrote:

> Hi Mason,
>
> > I would like to test babel protocol which is based on a distance vector
> > routing protocol.
>
> Cool.
>
> > In case of a wired network, e.g., RIP and OSPF, link state routing
> protocol
> > is generally known to be better than the distance vector routing one due
> to
> > fast convergence and loop-free property.
>
> That is common folklore, but it's not true.
>
>  - link-state is not intrinsically loop-free[1], it's just OSPF and
>    IS-IS that eliminate loops in a timely manner due to the reliable
>    flooding algorithm they use;
>  - while naïve distance-vector (GGP, RIP) generates loops, there exist
>    distance-vector protocols that are mostly loop-free (EIGRP, Babel,
>    DSDV).
>
> You may be interested in having a look at the slides of a lecture I've
> just given on the subject,
>
>  http://www.pps.jussieu.fr/~jch/enseignement/tbilisi2010.pdf<http://www.pps.jussieu.fr/%7Ejch/enseignement/tbilisi2010.pdf>
>
> > In a wireless network, AODV and DSR has been working better than DSDV
> > based on the distance vector one.
>
> AODV is a distance vector protocol.  DSDV's poor performance is not
> intrinsic to the protocol, it's due to having to wait for a periodic
> refresh after each starvation event (slide 46).
>

[msc] I've reviewed those documents and a paper. Thanks again for providing
a recent paper.


>
> > In addition, I also reviewed a paper which compared with various metrics
> > such as babel, batman, and olsr. Babel and batman outperformed olsr.
>
> OLSR is a very naïve variant of link-state -- it uses unreliable
> flooding.  I'm actually surprised it works as well as it does.
>
> > Incredible.
>
> Heh.
>
> > In general, for running manet's routing protocols, each wireless system
> has
> > to be set to an ad-hoc mode instead of AP or STA. In case of babel, all
> of
> > the wireless system has to be set to ad-hoc mode in a mandatory manner?
>
> > Unlike links between AP and STA, some wlan chipset working as ad-hoc mode
> > has not supported full throughput due to some firmware errors. In a worst
> > case, each wireless system cannot join the same cell infrequently. That'
> why
> > I want to avoid using ad-hoc mode due to the existence of unpredictable
> > characteristics. Instead of using an ad-hoc mode between wireless
> systems,
> > can I still use the babel between AP and STA (Client), on which the babel
> is
> > running separately?
>
> Babel only requires the ability to transmit IPv6 multicast on a link;
> a Wifi link in managed mode should be fine.
>
> The issue is different: in managed mode, nodes cannot associate
> arbitrarily: a STA cannot associate with a STA, an AP cannot associate
> with an AP, and a STA can only associate with one AP at a time.
>

But if your network topology is such that this is not a limitation, by
> all means, do try managed mode.
>

[msc] Like you commented, I've already configured a simple topology,

A-----B-----C

Each node has dual modes of master(AP) and sta(managed) at the same time. It
is working so well. But I will have a plan to increase the size of the
network and test it in details.

In addition, what about the future of Babel's recent IETF draft status? Is
it submitted to the IETF WG?


> Regards,
>
>                                        Juliusz
>
>
Myongsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20100908/4a171185/attachment.htm>