[olsr-dev] TC messages sent by non-MPR nodes

Eduard GV (spam-protected)
Mon Mar 6 21:03:38 CET 2006


Hi Andreas, thank you for your quick response.

> Hmm.. that sounds strange.

I agree.


> 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)
 |      /
 |   /
(D)

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
> >(spam-protected)
> >https://www.olsr.org/mailman/listinfo/olsr-dev
> >
> >
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>




More information about the Olsr-dev mailing list