Repository : ssh://git@open-mesh.org/doc

On branches: backup-redmine/2017-07-13,master

commit b49fc902371b481bde6e742008f8d7d9707fb31d Author: Marek Lindner mareklindner@neomailbox.ch Date: Wed Jul 8 11:47:58 2009 +0000

doc: batmand/Why-starting-batman

b49fc902371b481bde6e742008f8d7d9707fb31d batmand/Why-starting-batman.textile | 44 +++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+)

diff --git a/batmand/Why-starting-batman.textile b/batmand/Why-starting-batman.textile new file mode 100644 index 00000000..bc5830dc --- /dev/null +++ b/batmand/Why-starting-batman.textile @@ -0,0 +1,44 @@ + += Why starting B.A.T.M.A.N. ? = [[BR]] + +Often, we are asked why we dropped OLSR in favor of B.A.T.M.A.N. [[BR]] +To explain the initial motivation in those days to start developing a new [[BR]] +routing protocol optimized for lossy networks, we have summarized some [[BR]] +of those reasons in the following list in no particular order. [[BR]] + + * The OLSR protocol as specified in RFC 3626 was not completely [[BR]] + functional in practical scenarios. Tests in 2004 (namely at the [[BR]] + Wizards of OS conference) showed several issues like routing [[BR]] + tables taking a long time to build up and taking no time to break [[BR]] + down again, routing loops and flapping routes. We are not aware [[BR]] + of any mesh network installation in the field that runs the [[BR]] + protocol according to RFC3626 in a productive environment. If you [[BR]] + do, please let us know. [[BR]] + + * The OLSR protocol belongs to the family of link state routing [[BR]] + protocols which calculates a full routing path to all other [[BR]] + nodes in the network. All routing decisions rely on the fact [[BR]] + that every node has (mostly) the same information at any given [[BR]] + time. The more those information differ between the nodes in a [[BR]] + network, the probability of things like routing loops increases. [[BR]] + In our point of view, it is rather difficult to keep such [[BR]] + information synchronized in lossy environments like wireless [[BR]] + mesh networks, in that the effort needed for synchronisation [[BR]] + increases exponentially with each node. [[BR]] + + * The OLSR daemon as it is today (the one which can be [[BR]] + downloaded from www.olsr.org; we will further reference it just [[BR]] + as "OLSR daemon") comes with a lot of extensions / changes [[BR]] + (e.g. the default config disables most of the RFC3626 features as [[BR]] + MPR and enables ETX, !FishEye, etc) that alter the behaviour of [[BR]] + the routing protocol completely (compared to RFC 3626). [[BR]] + Those extensions have been developed by an active community [[BR]] + (Thomas Lopatic & Elektra and the OLSR-NG project later on). [[BR]] + Therefore the OLSR daemon today is not comparable with the [[BR]] + initial OLSR protocol at all, as many things which had been [[BR]] + specified in the RFC 3626 have been modified. Again, [[BR]] + because of our personal experiences, those extensions help [[BR]] + to decrease the problems inherited by the link state algorithm but are [[BR]] + unable to solve it which led to our decision, that it might be better [[BR]] + to try a different approach. [[BR]] +