[OLSR-users] Bellman-Ford instead of Dijkstra?

Thomas Lopatic (spam-protected)
Tue Jun 13 00:01:06 CEST 2006

Hey Benjamin,

I thought through your idea again and - although you already explained
it to me and I thought that I understood it - I am not quite sure any
longer whether I really get it. Let me try to put it into my own words
and see whether I understand what you're trying to accomplish.

You're trying to establish two links between a node A and a node B. For
this you have two interfaces per node, say A1 and A2 on node A as well
as B1 and B2 on node B. Say, A1 talks to B1, A2 talks to B2.

You would now like to use the A1/B1 link for packets from A to B. You
would like to use the A2/B2 link for the opposite direction, i.e. for
packets from B to A. In this way we would have a full-duplex connection
between A and B, packets could flow in both directions at the same time.

What this boils down to is an asymmetric scenario, doesn't it? From A's
point of view, we want to leave the A1/B1 link at its original link
quality and we want to make the A2/B2 link artificially bad, so that
A1/B1 gets prefered when node A sends packets to B. On B, we'd like to
make A1/B1 artificially bad and leave A2/B2, so that A2/B2 gets prefered
when B sends packets to A.

What this means is that A has another notion of the link quality of link
A1/B1 and link A2/B2 than B. For A the former is good and the latter is
bad, for B it's the other way around.

Based on this, let me ask two questions that came to my mind when
thinking through the scenario again.

 * We calculate our routing metric as follows: ETX = 1 / (NLQ x LQ). NLQ
is the quality of a link as reported by our neighbour (e.g. 0.7 if the
neighbour sees 70% of our packets), LQ is the quality of a link as
measured by us. So, I am not sure whether we can use ETX with asymmetric
routing as described above. The "LinkQualityMult" directive affects the
link quality that we measure (and then report to our neighbourhood). So,
if we use "LinkQualityMult" on a given link, then this link becomes
better or worse for us and for our neighbours. There currently isn't any
way to make us think that a link is good and at the same time our
neighbours think that the same link is bad - which is the basis for the
above asymmetric scenario, unless I am missing something here. Maybe the
solution is to simply announce the modified link quality to our
neighbours and ourselves use the original unmodified link quality. Hmm.

 * Why would the "LinkQualityMult" value have to be negative? Can't we
stick to Dijkstra, i.e. isn't 0 "bad" enough a multiplier? Hmmm. Could
you outline the scenario that you have in mind a little further?

Hmmm. As I (mis)understand the whole thing now, it rather looks like an
"asymmetric" kind of challenge and not that much a problem of negative
weights, or?


More information about the Olsr-users mailing list