|
|
| (27 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| == OLSR vs B.A.T.M.A.N ==
| |
|
| |
|
| This discussion is around what mesh routing protocol to use for our High Performance Nodes in die APEX3 project. Before we look into the protocols we need to understand the environment where the HPNs are going to be used in, who's going to install and maintain the network and what other system requirements will have an influence on the protocol selection.
| | migrated to wireless dev |
| | |
| From the APEX3 contract (that we haven't seen yet) it is clear that the target is not a pilot/research network, but a real commercial network that must provide connectivity to several schools and government departments, as well as for the community. The installation and maintenance will be the responsibility of external (not Meraka/CSIR) partners. This means that it's not a research network and whatever protocol we select needs to be very stable and well tested. Another requirement is that the network should be so easy do install and maintain that it can be done by someone in the community (It must not need an Engineer to design/configure/tweak the network before it is usable).
| |
| | |
| The biggest requirement of any network is that it should be stable. After that you get all the other features like speed, ease of use, supported features etc. In a development network one can tolerate some degree of instability while working on new functionalities, but on a network that will be used by other parties should be rock solid and stable. The biggest factor about introducing any new protocols in a network, is that one needs a certain amount of time (years) to test, fix bugs and make sure that everything is stable and usable.
| |
| | |
| === OLSR ===
| |
| | |
| Pros
| |
| * Proven and stable
| |
| * Scales well
| |
| * Support both IPv4 and IPv6
| |
| | |
| Conns
| |
| * Routing information packets can become big
| |
| * Lots of network overheads to food routing information
| |
| | |
| === B.A.T.M.A.N ===
| |
| | |
| B.A.T.M.A.N is a fairly new protocol with many different versions, flavors (L2, L3) and derivatives (R.O.B.I.N, Mikrotik MME).
| |
| | |
| ==== B.A.T.M.A.N L2 ====
| |
| Pros
| |
| * Works on L2 and is protocol independent (support both IPv4 and IPv6)
| |
| * Can use DHCP for automatic IPv4 addressing
| |
| | |
| Conns
| |
| * No FreeBSD port
| |
| * Not mature protocol, still in developing state
| |
| * Problems with multi-radio nodes: https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-February/002405.html
| |
| | |
| ==== B.A.T.M.A.N L3 ====
| |
| Batman was designed for a single radio, single channel mesh.
| |
| | |
| Pros
| |
| | |
| Conns
| |
| * No IPv6 support
| |
| * No FreeBSD port
| |
| * Not mature protocol, still in developing state
| |
| | |
| Random thoughts that I need to sort.
| |
| *
| |