|
|
| (14 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| == FreeBSD vs Linux ==
| |
|
| |
|
| === FreeBSD ===
| | migrated to wireless dev |
| | |
| | |
| === Linux ===
| |
| | |
| == 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.
| |
| | |
| 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 (auto configure) and maintain and 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, lots of big networks using it
| |
| * Scales well
| |
| * Support both IPv4 and IPv6
| |
| * Support for Linux, FreeBSD, MacOS
| |
| * Active development
| |
| | |
| Conns
| |
| * Routing information packets can become big
| |
| * Lots of network overheads to food routing information
| |
| * Can cause high CPU loads on small CPU's in low cost HW platforms
| |
| * Has difficulty routing in the presence of multiple gateways on the mesh
| |
| | |
| === 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).
| |
| https://www.open-mesh.net/wiki/BranchesExplained
| |
| | |
| ==== B.A.T.M.A.N Layer2 ====
| |
| Pros
| |
| * Works on L2 and is protocol independent (support both IPv4 and IPv6)
| |
| * Can use DHCP for automatic IPv4 addressing
| |
| * Small and effective routing table
| |
| | |
| Conns
| |
| * No FreeBSD port
| |
| * Not a mature protocol, still in developing state
| |
| * Seems like B.A.T.M.A.N development is more active with the Layer3 version than the Layer2 one
| |
| * 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 Layer3 ====
| |
| | |
| Pros
| |
| * Small and effective routing table
| |
| * Smaller, less frequent routing information packets flooding the network
| |
| * Cannot have routing loops (according to the design, but some people seem to differ)
| |
| http://www.mail-archive.com/babel-users@lists.alioth.debian.org/msg00148.html
| |
| * Active development
| |
| * Intelligent management of multiple gateways with varying bandwidth characteristics
| |
| | |
| Conns
| |
| * No IPv6 support
| |
| * No FreeBSD port
| |
| ** In progress: http://www.mail-archive.com/b.a.t.m.a.n@open-mesh.net/msg00560.html
| |
| * Not a mature protocol, still in developing state
| |
| | |
| === Random thoughts. ===
| |
| * Our current Meraka team only have experience with OLSR, but not with BATMAN (Except for David, but he's overseas). Maybe we need to setup a test network to get a feeling of the amount of tweaking that is needed to get it to run and how much is done automatically. In the end we want a mesh node that is totally auto configured, including all IPv4 and IPv6 addresses.
| |
| ** I (Antoine) am in the process of helping George set up a small B.A.T.M.A.N. mesh for the dashboard development work.
| |
| * A google search for a up-to-date comparison between OLSR and BATMAN did not deliver much. From a quick scan in a couple articles and comments it seems like OLSR is very stable and performs well in mesh networks, but BATMAN seems to be very promising and may be the preferred mesh protocol in future.
| |
| * With another google search I could find a couple of big operational networks based on OLSR, but I could not find any big operational BATMAN networks. If there are any big operational BATMAN networks out there then I would really like to get more information and comments on it.
| |
| ** http://wiki.opennet-initiative.de/index.php - mixed OLSR & B.A.T.M.A.N.
| |
| ** http://wiki.leipzig.freifunk.net/BATMAN - mixed OLSR & B.A.T.M.A.N.
| |
| ** http://www.open-mesh.net/wiki/BerlinExperience
| |
| ** http://www.open-mesh.net/wiki/Experience
| |
| * Meraka has an operational and stable HPN node that is based on FreeBSD. The current HPN mesh protocol is OLSR and the mesh supports both IPv4 and IPv6. The biggest drawback at the moment is that it does not have an user interface and some vi tweaking is needed.
| |
| * The exhaustion of the remaining pool of unallocated IPv4 addresses is approaching within the next few years. IPv4 will not expire or stop to work, but there will be an migration phase where both IPv4 and IPv6 will be used. Some new services and web sites will only be reachable via IPv6. The default protocol on most operating systems are IPv6 and there is a big drive from Microsoft to push IPv6. We cannot just stick our heads in the ground and ignore this fact like an Ostridge. Our current HPN have full IPv6 support and it will not make a lot of sense move backwards to something that does not support IPv6. If we do feel like BATMAN is a better choice then it will make sense to add IPv6 support to it as well.
| |
| * Is there enough development time and money on the APEX3 project to add a lot of new and promising features to the HPN, or should we rather concentrate on the parts that are missing in order to get a stable network out there.
| |