On Dienstag 23 Dezember 2008 16:27:38 Juliusz Chroboczek wrote: > >> I believe that Babel's neighbour discovery mechanism is smarter than the > >> one in NHDP. > > > > In which way ? Maybe you can give me some pointers to look into the babel > > documentation. > > Section 3.4.1 of the protocol spec, which is implemented in the function > update_neighbour in the Babel sample implementation. Hmm... on a first look it does seem to be a straight forward Hello mechanism with adaptive timings, which are allowed in NHDP. I think I even remember NHDP talk about constraints how you can change the data rate and tell it your neighbors correctly.
> > In addition to this TimeTLV solves the problem if different timeouts > > depending on the hopcount (very important for fisheye implementations). > > I'll try to understand that. Think about it this way. Most times you have timeouts which are proportional to your message generation rate (a link is valid up to 4 hello timeouts for example). With a fisheye implementation your message rate becomes a function of distance. TimeTLV allows you to say (within a few bytes): - Hopcount 1 to a: Value 1 - Hopcount a+1 to b: Value 2 - Hopcount b+2 to infinity: Value 3 (the data above would be encoded into 5 bytes) > I'd rather you explained how OLSRv2 solves the problems of mis-behaviour of > link-state in unstable networks. I do understand the mechanisms that avoid > this misbehaviour in OSPF. I've seen no such mechanisms in OLSRv2. Unstable links should be handled on a link level... just create a routing metric that add a penalty to unstable link so you try to use better links. Markus Kittenberg has done some very interesting experiments with this (not with real OLSR nodes, just number crunching at the moment). Henning
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
