On Sat, 2006-12-30 at 20:11 +0100, thomasasta@gmx.net wrote:
[...]
> I have a question too,
[...]
> - I read about the new Ieee 802s or what it was called and it was
                IEEE 802.11s
>  stated, that a routning on a MAC-Level is better than a routing on a
> IP level. Why is OLSR then not switching?

I didn't read details (e.g. the standard) about it either but AFAIK:
- They (want to) support AODV (re-active) and OLSR (pro-active
  "routing") with - in my impression of what I heard/read - AODV has the
  higher priority (and I do absolutely not know where this comes from -
  can be well because of some person working on it and thus more
  progress/practical usability).
- Putting "OLSRD into the MAC layer" sounds great and simple. As with
  most great and simple ideas, things get more complicated if you look
  into details like
  * how similar is the 802.11s protocol messages and behaviour?
  * at least for Linux this implies making a kernel module out of the
    the user-space daemon. While this is not rocket science, is it a lot
    of work (e.g. has a kernel usually no C-library[0], very little
    space on the stack and to "sleep" cannot done with a simple function
    call. And the interface to the IP layer above and the core MAC layer
    is probably different to the current one).
  * Not all of the daemon makes sense in kernel space (e.g. most of the
    plugins). So if the goal is inclusion into the official Linux
    kernel (which IMHO must be a goal) implies an interface (e.g. a char
    driver at least) from the kernel part to the user-space, otherwise
    it will IMHO not be included.
  * The license of OLSRD is BSD. Putting parts into the kernel implies
    rewriting these since is needs GPL. Period.
  * Interfacing with different MAC layer implementations (Ethernet,
    Wireless, FDDI, ...) must be implemented and tested. I never dug
    into that part of kernel hacking yet so I don't know if and how this
    could be possible (not even in theory) - or even the needed effort.
    Do you know anyone who is willing to fund a journey on a road with
    unknown length?
  * Can 802.11s work with MAC addresses of different lengths (Ethernet
    and most others have 6 bytes, FDDI has 14 IIRC)?
  * And while I'm at it: What is with VLANs?
  * What to do if one detects duplicate MAC addresses?
    Yes, I know the theory about "no duplicate MAC addresses" but given
    the vast amount of of network cards of 3Com, RTL, etc. I doubt that
    the "Ostrich algorithm"[1] will be sufficient.
  * How large are the networks?
    If you get 1E6 nodes, your ARP table will have (at least!) 1E6
    lines (and the needed RAM for it). Have fun with that on small
    hardware.
  On the positive side:
  * One gets rid of a routing daemon on every node.

Don't get me wrong I sure it is absolutely possible and doable - it is
just a lot of work.

	Bernd

[0]: Some of the simpler functions are available but not all ...
[1]: http://en.wikipedia.org/wiki/Ostrich_algorithm
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



