[olsr-dev] TC messages sent by non-MPR nodes
Mon Mar 6 21:03:38 CET 2006
Hi Andreas, thank you for your quick response.
> Hmm.. that sounds strange.
> If TC redundancy is set to 0 a node is
> only to announce its MPR selectors. This means that a node will
> only transmit TCs if it is selected as a MPR.
AFAIK, yes inedeed.
> The olsr.org implementation should work this way(in both RFC
> and LQ mode AFAIK).
In fact, it does this way (when TCRedundancy=0). When TCReduncancy =
2, theoretically, MPRs should also send all their detected neighbors
(i.e. not only MPR-selector set).
> What nodes are the non-MPR-selectors announcing in their TC messages
> in your setup?
I'm not sure I've understand your last question, just in case I
describe a simple scenario:
(A) --- (B) -- (C)
i.e. links: A<->B; A<->D; B<->C; B<->D. All nodes with TCRedundancy =
2. B is the only MPR (selected by A, C and D).
A sends TC messages announcing B
B sends TC messages announcing A, C, D
C sends TC messages announcing A, B
D sends TC messages announcing B
Note that C becomes aware of link A<->D when, IMHO it never should had happen.
The problem here may be only in my mind, because I thought TC messages
were only sent by MPR nodes independently of TCRedundancy parameter.
But as I said, it could be a misinterpretation of the RFC.
> - Andreas
> Eduard GV wrote:
> >Hi all,
> >According to RFC 3626 (9.3): "In order to build the topology
> >information base, each node, which has been selected as MPR,
> >broadcasts Topology Control (TC) messages."
> >I understood that only MPR nodes sent TC messages, but testing
> >different values of TC_REDUNDANCY Parameter, I saw that actually ALL
> >nodes send TC messages. When TC_REDUNDANCY = 2, all nodes broadcast
> >their neighboring set, independently of their MPR condition.
> >Both Unik's and INRIA's OLSRs perform likewise (though INRIA's detects
> >an "inconsistency" when working with TC_REDUNDANCY=2).
> >...so I guess I misinterpreted the RFC jargon. Am I right (now), or is it a bug?
> >Sometimes it seems that you need to be a lawyer to understand
> >technical documentation :(
> >Thank you.
> >olsr-dev mailing list
> olsr-dev mailing list
More information about the Olsr-dev