[OLSR-users] Differing metrics for route decision
Roar Bjørgum Rotvik
Mon Feb 27 08:27:03 CET 2006
Thomas Lopatic wrote:
> Hey Liam.
>> How was the ETX metric implemented into the main olsr codebase?
> Currently there isn't any clean plugin-like interface for metrics. The
> ETX implementation hooks into the code of olsrd at quite a lot of places
> which are dispersed all over the code.
> Regarding other metrics or improvements of the existing metric we're
> always open for discussion. I am not a routing expert, though, I just
> implement what other, smarter people tell me to implement. :-)
I just wanted to tell you that I also thought about changing the
metric/route calculation in OLSR, and looked at the code.
My idea was to start with the ETX code, but just replace the code where
the calculation takes place to match my own calculation, but reuse much
of the ETX infrastructure.
I worked on a project where each node had two radios, one long range and
low bandwidth, second radio had short range and high bandwidth.
In this scenario each node will probably hear another over the long
range radio, but if you want to transmit for instance video streaming
over two hop, you would like to use two short range instead of one long
range because of the bandwidth requirements.
In this case the metric would be interface "cost", where the long range
radio/interface has a higher cost than the short range radio. But when
number of hops on short radio reaches a certain limit (let say 2-3
hops), then we would like to use one long range hop instead (for traffic
suited for this bandwidth of course. Video cannot be sent over this
So I looked into changing ETX calculation from quality metric to cost
metric, it seemed possible to do without to much trouble. But
unfortunately I did not have time in the project to implement this.
But I saw that if olsrd had a plugin-like solution to the metric
calculation, it would be a lot easier to implement and test new
calculations and maybe come up with range of better metrics. The
standard OLSR lowest-hop-count is clearly not the best solution
If I'm correct OLSRD today have three methods to calculate
metric/routing: OLSR, ETX and Fisheye.
Would it be simpler to maintain (less code duplication and so on) if
olsrd had a common generic framework for the metric/routing calculation
and plugin-like support for the actual calculation? Just an idea..
NB: Sending this email to olsr-dev with CC to olsr-user, as I think
olsr-dev is the most appropriate for this kind of discussions.
Roar Bjørgum Rotvik
More information about the Olsr-users