Hi batman developers,
Clara Gnos suggested that I write to the list to make a case for batman + 802.11s integration. As you probably know, 802.11s is the upcoming wireless mesh standard from IEEE. The current version of the draft was approved by the IEEE 802 Executive Committee in July and will be ratified next month. open80211s (http://o11s.org) is an open implementation of 802.11s that's in the kernel mainline since 2.6.26.
802.11s uses HWMP as its default routing (path selection, in 11s-speak) protocol. All 11s implementations must support this default, and this is what's implemented in open80211s. The 11s spec also defines an extensible framework to support other path selection protocols and custom metrics. open80211s supports these by providing userspace hooks for custom path selection daemons.
Which brings me to the main point of my e-mail: is anyone out there interested in porting batman's path selection algorithm into open80211s? The benefits:
1. By being based on a standard, you'll know you won't be colliding with other layer 2 technologies (for instance, no need to define your own ethertype) 2. You can leverage most of open80211s, from test tools to wireshark patches. 3. By being integrated in the kernel's 802.11 stack, you can take advantage of the development that's taking place there, from encrypted management frames to HT support. 4. You can reach out to a larger development community and raise awareness about batman. 5. A big problem in mesh adoption on Linux is not the mesh protocol itself but the absence of simple to use configuration tools (e.g. no mesh support in ConnMan, NetworkManager, etc.). By providing a unified wireless mesh framework we increase the likelihood of having some support at the distro level. and last, but not least... 6. You'll be able to say authoritatively that batman is X times more efficient than HWMP (pick any X greater than 1 :)
Anyway, that was just a thought. If anyone is interested let me know.
Cheers,
Javier
On Monday 22 August 2011 16:30:56 Javier Cardona wrote:
Which brings me to the main point of my e-mail: is anyone out there interested in porting batman's path selection algorithm into open80211s?
Which one? There are ~5 revisions of the algorithm (not implementations). The newest iteration is B.A.T.M.A.N. V and is currently in the research and prototyping phase. The algorithm described in the RFC draft was B.A.T.M.A.N. III
...but I am not interested in implementing it for 802.11s. Maybe there is somebody else. Most people are currently focused on batman-adv. So I will write this response with batman-adv in mind.
The benefits:
I only see benefits mentioned by you, but were are the disadvantages? I don't think that a marketing mail is a good start for a serious discussion.
- By being based on a standard, you'll know you won't be colliding
with other layer 2 technologies (for instance, no need to define your own ethertype)
At least batman-adv is quite happy about the fact that it is based on a widely used standard technology. And defining another identificator instead of an ethertype doesn't make a big difference to me.
But why are we colliding with any other layer 2 technologies? It sounds like "uh, you are so bad. you kill cute bunnies", but I don't see the "colliding" problem here. Maybe you mean the missing ethertype registration (anyone got $2500 for us?).
- You can leverage most of open80211s, from test tools to wireshark
patches.
batman-adv also has wireshark integration (already upstream) and test tools.
- By being integrated in the kernel's 802.11 stack, you can take
advantage of the development that's taking place there, from encrypted management frames to HT support.
Aren't all those things part of the layer _below_ batman-adv? Why should we care about it when the stuff we use has to deal with it.
- You can reach out to a larger development community and raise
awareness about batman.
What larger development community? At least the open80211s community seems to be a lot more silent.
- A big problem in mesh adoption on Linux is not the mesh protocol
itself but the absence of simple to use configuration tools (e.g. no mesh support in ConnMan, NetworkManager, etc.). By providing a unified wireless mesh framework we increase the likelihood of having some support at the distro level.
Hm, maybe we have a different target audience. batman-adv is made for routers/APs and not for desktop systems. Thats why it has client mac propagation, bridge loop avoidence and roaming announcements (and many more things with funny names). And we already have a relative good distro integration for our target group...
and last, but not least... 6. You'll be able to say authoritatively that batman is X times more efficient than HWMP (pick any X greater than 1 :)
And this is important because... And can be measured by... And uses the normed scale...
Maybe you should visit a Wireless Battle of the Mesh and tell them how such a benchmark is correctly done.
Greetings, Sven
Hi Sven,
On Tue, Aug 23, 2011 at 3:32 AM, Sven Eckelmann sven@narfation.org wrote:
On Monday 22 August 2011 16:30:56 Javier Cardona wrote:
Which brings me to the main point of my e-mail: is anyone out there interested in porting batman's path selection algorithm into open80211s?
Which one? There are ~5 revisions of the algorithm (not implementations). The newest iteration is B.A.T.M.A.N. V and is currently in the research and prototyping phase. The algorithm described in the RFC draft was B.A.T.M.A.N. III
Thanks for pointing that out. I did not know there were that many versions.
...but I am not interested in implementing it for 802.11s. Maybe there is somebody else. Most people are currently focused on batman-adv. So I will write this response with batman-adv in mind.
Noted.
The benefits:
I only see benefits mentioned by you, but were are the disadvantages? I don't think that a marketing mail is a good start for a serious discussion.
??
- By being based on a standard, you'll know you won't be colliding
with other layer 2 technologies (for instance, no need to define your own ethertype)
At least batman-adv is quite happy about the fact that it is based on a widely used standard technology. And defining another identificator instead of an ethertype doesn't make a big difference to me.
But why are we colliding with any other layer 2 technologies? It sounds like "uh, you are so bad. you kill cute bunnies", but I don't see the "colliding" problem here. Maybe you mean the missing ethertype registration (anyone got $2500 for us?).
By colliding I mean "come into conflict or opposition", not killing bunnies. And it happens to be the same verb that Simon Wunderlich used to explain why batman-adv had to change its ethertype (https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-August/001682.html). Of course it's not a big deal, but definitely something you need not worry about if your implementation is based on a spec that has been standardized.
- You can leverage most of open80211s, from test tools to wireshark
patches.
batman-adv also has wireshark integration (already upstream) and test tools.
Nice.
- By being integrated in the kernel's 802.11 stack, you can take
advantage of the development that's taking place there, from encrypted management frames to HT support.
Aren't all those things part of the layer _below_ batman-adv? Why should we care about it when the stuff we use has to deal with it.
I see. If I understand correctly batman-adv works as a bridge, encapsulating mesh management info into data frames. In that case batman-adv routing must be based on hopcount and/or transmission failures as radio layer info is lost in the conversion to 802.3. By being in the 802.11 stack, 11s has more information about the quality of the links and can use that information to compute a finer-grained metric. The standard defines airtime as the default link metric but 11s can be extended to include other info like RSSI or SNR.
A similar argument can be made about security. I assume batman-adv does not implement security but instead relies on whatever the lower layer provides. In 11s security is built from the ground up. Peers authenticate each other and exchange encryption keys at the same time they establish a peer link. Security becomes easier to manage and more robust than when using, for instance, WPA to secure peer links.
- You can reach out to a larger development community and raise
awareness about batman.
What larger development community? At least the open80211s community seems to be a lot more silent.
No matter how silent or small the open80211s community is, batman-adv + open80211s will always be larger than batman-adv alone. That's what I meant by "larger".
- A big problem in mesh adoption on Linux is not the mesh protocol
itself but the absence of simple to use configuration tools (e.g. no mesh support in ConnMan, NetworkManager, etc.). By providing a unified wireless mesh framework we increase the likelihood of having some support at the distro level.
Hm, maybe we have a different target audience. batman-adv is made for routers/APs and not for desktop systems.
Why limit yourself there? There are definitely use cases for non-routers to join a mesh network.
Thats why it has client mac propagation, bridge loop avoidence and roaming announcements (and many more things with funny names).
IEEE 802 also has its share of funny names...
client mac propagation, roaming announcements = (802.11s, Sec. 7.3.2.116) Proxy Updates bridge loop avoidance = (802.1D, Sec. 17) Rapid Spanning Tree Protocol or my favorite: (802.11s, Sec 8.2a.1) Simultaneous Authentication of Equals
And we already have a relative good distro integration for our target group...
Agree to that. openwrt rocks.
and last, but not least... 6. You'll be able to say authoritatively that batman is X times more efficient than HWMP (pick any X greater than 1 :)
And this is important because... And can be measured by... And uses the normed scale...
Maybe you should visit a Wireless Battle of the Mesh and tell them how such a benchmark is correctly done.
You mean the same Wireless Battle of Mesh that year after year fails to decide on a winner? :) (My sixth point as well as the response above should be taken humorously, that's what the colon thingy at the end of the sentence meant)
I could not help noticing a certain level of skepticism in your response. I'm not trying to sell anything nor asking anyone to dump batman in favor of anything else. I admire and respect what the batman project has achieved so far. Even people in open80211s' mailing list criticize that batman performs much better than open80211s ( http://open80211s.com/pipermail/devel/2011-August/000859.html). But my impression is that, maybe because they were ahead of their time, the batman community had to invent/reinvent things in their own 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.
Greetings and congratulations for your good work.
Cheers,
Javier
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
Hi Andrew,
On Wed, Aug 24, 2011 at 12:18 AM, Andrew Lunn andrew@lunn.ch wrote:
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'm on equal footing regarding batman: thanks for taking the time to help me understand the differences between the two.
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?
If yes, great, anybody setting up a static routes, babel, olsr, BMX, and batman{-adv} mesh can just use there services.
Based on my current understanding it looks like you could establish a batman-adv network over 1-hop 11s links. Interesting.
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.
Thanks a lot for sharing your thoughts on this.
Cheers,
Javier
Hi Javier,
On Wed, Aug 24, 2011 at 11:30:01AM -0700, Javier Cardona wrote:
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.
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. :)
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.
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. ;)
(...)
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?
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.
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.
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-step... [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
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.
STP, RSTP protocols are good when the networks are nearly perfect. However, wifi is no way near perfect, there is high packet loss. So when deciding to block ports, to resolve loops, you want to block the wireless part and keep the wired part working. It can be hard to make STP and RSTP do this, it often blocks the wired part, so making your overall network work badly. Read the page, it explains the concept quite well.
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.
BATMAN does not really care if the WiFi is in infrastructure mode of adhoc. However, generally, it is used in adhoc. Maybe the 802.11s authentication and encryption schemes don't make too much sense in infrastructure mode, but it would be nice to be able to use them in adhoc mode.
Does batman-adv provide a security layer above the link layer security (and below IP)? If so, where can I read more about that?
Nope. That is a problem for some other layer, e.g. the link layer below, IPSEC above, TLS end to end etc...
Based on my current understanding it looks like you could establish a batman-adv network over 1-hop 11s links. Interesting.
I expect it will also work over 42-hop 11s links. It probably won't have the "optimal" toplogy, by some definition of "optimal".
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.
Actually, most of the mesh protocols i listed try to minimizing the spectrum. They try to use wired as much as possible! Wired links give a much better goodput compared to wireless, so that it is better to take a longer low bandwidth looking path over wired than a shorter higher bandwidth looking path over wireless.
I'm not a PHY person, but i've seen papers from coding/PHY people who actually say you should be maximizing spectrum utilization, not minimizing it. If i understand the research correctly, you get better overall mesh performance by sending for a long time a 6Mbps at lower power, compared to sending a short burst at 54Mbps at high power. To receive at 6Mbps you need a much lower SNR than at 54Mbps. So you can transmit at lower power, so causing less interference to others and receive in a noisier environment at 6Mbps, than receive a 54MBps frame which needs more transmit power and less background noise in order to receive it. So 6Mbps at lower power allows more links to be active at the same time, maximizing the overall mesh bandwidth/latency. But like i said, i'm not a PHY person, so i might have this all wrong.
Most mesh protocols actually go partway towards this. They all roughly approximate to "least number of hops over good links", by some definition of "good link". Least hops generally means using long hops, which will naturally have less bits per symbol, i.e more medium time. All that is missing is power control in the wireless layer.
Andrew
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
Javier Cardona -
Simon Wunderlich -
Sven Eckelmann