<div>hmm olsrd (stable branch) has a metric plugin interface,..</div><div>(but currently there are not much plugins around,..)</div><div><br></div><div>and olsrd has the lqmult factor to tune linkquality a bit,..</div><div>
<br></div><div>olsrd "0.7.0" will have olsrv2 packet format, allwoing to add custom fields for really complex or multiple metrics aswell,.. </div><div><br></div><div>Markus</div><div><br></div><div class="gmail_quote">
On Sun, May 15, 2011 at 1:20 PM, Benny Baumann <span dir="ltr"><<a href="mailto:BenBE1987@gmx.net">BenBE1987@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
when building a larger network which is (partly) interconnected by<br>
infrastructure abroad routing the traffic inside the network gets more<br>
complicated than when you only have a flat structure of ad-hoc access<br>
points meshing a local network.<br>
<br>
Now let's assume you have the following situation:<br>
<br>
1. 3 local networks A, B, C each consisting of roughtly 50-100 nodes.<br>
2. An infrastructure network D consisting of 5-10 nodes which<br>
interconnects through VPN/Tinc. Due to the nature of the VPN all routes<br>
inside the VPN are seen with ETX 1 (between all nodes)<br>
3. One of the nodes in the networks A, B and C (each) has a VPN<br>
connection to D<br>
<br>
Given this basic network layout routing traffic is kinda straight<br>
forward as if you want to go from one of the local networks to another<br>
one since taking the inter-connect network D is the only route to go.<br>
<br>
Let us further assume, you built some new access points that<br>
interconnect A, B and C directly (direct wireless link). Given this was<br>
a wireless link you'd probably be much better than taking a DSL or cable<br>
line from A to D to B (D being around the globe). Instead the new<br>
wireless link would be much better. Unfortunately in regards to the<br>
hop-count D might be the shorter path, but latency-wise D might be just<br>
the most horrible choice you could do (e.g. UMTS or satelite uplink).<br>
<br>
Now as I understood the workings of OLSR there's the nice feature called<br>
ETX, which calculates link quality and estimates which way our packet<br>
would get to its destination the best.. Though if you have a VPN which<br>
interconnects different networks this ETX metric is rendered worthless<br>
as most VPN links should appear as ETX 1 (and practically always do)<br>
while the better direct link might have an ETX of let's say 1.5 (due to<br>
lots of angry birds crossing the way).<br>
<br>
When having a look at latency it's basically identical: The longer a<br>
packet needs to transmit the worse is the link quality for the user<br>
(e.g. for real-time applications). But OLSR doesn't take this into<br>
consideration. Not to mention band-width control and load-balancing<br>
(which is out of scope for now as this can be achieved with means other<br>
than OLSR).<br>
<br>
So now for the actual question: Is it possible (in OLSR 0.6 or later) to<br>
influence the Link Quality for a node through a plugin? E.g. make OLSR<br>
use Latency*LQ as the weight for a link, instead of plain 1/LQ?<br>
<br>
Are there means to introduce such additional metrics in a portable way?<br>
I.e. without rehacking the packet parser or introducing lots of new<br>
packets that would have to be flooded (separately) into the network? How<br>
much work would it be to implement such a mechanism?<br>
<br>
Regards,<br>
<font color="#888888">Benny Baumann<br>
<br>
</font><br>--<br>
Olsr-dev mailing list<br>
<a href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-dev" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-dev</a><br></blockquote></div><br>