24 Aug
2011
24 Aug
'11
10:23 p.m.
Hi Javier,
On Wed, Aug 24, 2011 at 11:30:01AM -0700, Javier Cardona wrote:
The bridge loop avoidance is a little bit different from (R)STP. It also
avoids loops, but at the same time tries to offer the wireless clients
coming from the mesh the best way into the wired backhaul (i.e. select
the best router for this task). At this point, (R)STP could be also used,
but it usually just randomly kill of links, not neccesarily based on
transmit quality. :)
batman-adv usually sees non-wireless links as "perfect" links, as there
is no packet loss. There is no "special" support (it may be interesting
to further qualify bandwidth or latency), but it just blends in
transparently. That's the beauty. ;)
Have a look WPA-NONE. It is not well documented, but it basically works
with a single shared key and CCMP/AES encryption. No peer-to-peer
session keys or stuff like that though, afaik.
Mhm, heterogenous network support is definitly one strength of batman.
However, with its general design we have a broad bandwidth where
we can optimize and experiment, for example:
* multiple interfaces support in general (does 802.11s allow to span
meshes over multiple radios?), and with this:
* interface alternating (receive on wlan0, send on wlan1) [1]
* bonding (send on wlan0 and wlan1 in a round robin fashion) [1]
* full duplex (not implemented, but might be someday ;)
* network coding (we have some recent research on this) [2]
* optimized multicast transfer [3]
* further support for some protocols, like ARP [4]
(through distributed hash tables, a current GSoC project)
* the "core" routing too, of course :)
...
Regarding the battlemesh - we have seen some interesting effects in
the battlemeshes, but personally I see these events as an excellent
way to meet people, discuss experiences and ideas and primarily have
a lot of fun. ;) It is one of the rare occasions that most of the
batman developers meet. You should come next time if you can. :)
The "real" tests and live experience is gathered inside real mesh networks, e.g.
community networks or commercial networks with routers which include
batman-adv as their mesh network software (using *WRT or commercial firmwares).
Many features which were developed (e.g. Gateway support [5], Bridge Loop
Avoidance [6], Multicast Support [3], ...) came directly from
"real world requirements".
Thanks for your input!
best regards,
Simon
[1] http://www.open-mesh.org/wiki/batman-adv/Bonding-alternating
[2] http://www.open-mesh.org/wiki/open-mesh/2011-08-18-network-coding-first-ste…
[3] http://downloads.open-mesh.org/batman/misc/wbmv4-multicast.avi
[4] http://www.open-mesh.org/wiki/batman-adv/DAT
[5] http://www.open-mesh.org/wiki/batman-adv/Gateways
[6] http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance
I actually
think IEEE 802.11s needs to first evolve and become part of
IEEE802.1. The problem is, mesh != wireless, so having it part of
802.11 limits its application way too much.
802.11s is designed to fit within the IEEE 802 family of protocols (it
was approved by the IEEE 802 Executive Committee in July). You are
correct in that 11s does restrict the mesh to be a wireless mesh. But
it is designed to connect to external networks via 802.1D bridges.
802.1D bridges have been around for ages and are good at
interconnecting diverse MAC types without routing loops. I read here
(http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance) that
batman implements its own loop-avoidance protocol which, from my
limited perspective, seems redundant.
I've been
to a few of the wireless battlemesh events and gained some
experience with real mesh network. One thing which is very clear to me
is, they are multi-technology. They mix 802.11, 802.3, cable modems,
VPN, and in theory, there is no reason why avian carriers could not be
used.
If you look at the mesh routing protocols represented in battlemesh,
static routes, babel, olsr, BMX, and batman{-adv} all are multi
technology and have no problem building one mesh over a heterogeneous
network.
I can appreciate the benefits of supporting a diversity of link
technologies. I'd have to understand better how a single metric
definition can be used to quantify the quality of all link types, from
802.11 to homing pigeon. But I guess it's being done successfully.
(...)
You also said 802.11s contains device authentication, encryption,
etc. This also seems to me to be the wrong layering. These should be
generic services which any 802.11 "mode" above can use.
Can these services be used in adhoc mode or managed mode?
In 802.11 infrastructure mode you have only one authenticator (the AP)
and many supplicants. You cannot use the same security model in a
mesh, when there are no such role divisions. Does batman-adv provide
a security layer above the link layer security (and below IP)? If so,
where can I read more about that?
My personal
opinion is that taking the multi-technology batman-adv
protocol and shoehorning it into the single technology 802.11s is the
wrong way to go. What might however be interesting is taking a closer
look at 802.11s and see what can be generalized and moved up into
babel, olsr, BMX, and batman{-adv}, or merged into plain old managed
mode and adhoc mode 802.11 and offered as services to layers above.
When I wrote my first e-mail to your list I was under the impression
was that batman-adv's routing algorithm was more advanced than HWMP,
mainly because it had incorporated improvements gathered from many
deployments (... and mesh battles :). But it seems like batman's main
strength is its ability to establish routes over heterogeneous links,
not necessarily minimizing the spectrum utilization.