HPN design discussions page: Difference between revisions
(New page: == OLSR vs B.A.T.M.A.N Layer2 vs B.A.T.M.A.N Layer3 == The biggest requirement of any network is that it should be stable. After that you get all the other features like speed, ease of us...) |
|||
| Line 1: | Line 1: | ||
== OLSR vs B.A.T.M.A.N | == OLSR vs B.A.T.M.A.N == | ||
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 to test and make sure that everything is stable and usable. | 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, how'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) it is clear that the target is not a pilot 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 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 === | === OLSR === | ||
Pros | Pros | ||
* Proven and stable | * Proven and stable | ||
| Line 13: | Line 18: | ||
* Lots of network overheads to food routing information | * Lots of network overheads to food routing information | ||
=== B.A.T.M.A.N L2 === | === 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 | Pros | ||
* Works on L2 and is protocol independent (support both IPv4 and IPv6) | * Works on L2 and is protocol independent (support both IPv4 and IPv6) | ||
| Line 23: | Line 32: | ||
* Problems with multi-radio nodes: https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-February/002405.html | * 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 === | ==== B.A.T.M.A.N L3 ==== | ||
Batman was designed for a single radio, single channel mesh. | Batman was designed for a single radio, single channel mesh. | ||
Revision as of 09:41, 20 March 2009
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, how'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) it is clear that the target is not a pilot 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 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.