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