> unique way. And now that a standard is in place, everyone interested
> in mesh could benefit if there was a seventh (and final) version bump
> to bring it in line with IEEE 802.11s.
Hi Javier
I don't know that much about 802.11s, so i would be very happy to be
wrong....
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.
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.
What a mesh technology ideally wants is a collection of links which it
can send ethernet or IP frames over. So this puts it somewhere in
802.1, or a sublayer of IP.
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? If yes, great, anybody
setting up a static routes, babel, olsr, BMX, and batman{-adv} mesh
can just use there services.
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.
Andrew
