<br>Hi all,<br><br>The last message sent in the list brought me some doubts about the technical details of olsrd.<br><br>First: in <a href="http://www.olsr.org/docs/README-Link-Quality.html">http://www.olsr.org/docs/README-Link-Quality.html
</a> it is discussed about the Link Quality Extension to OLSR and how it is implemented in olsrd. But according to the text mentioned by Andreas in his last message (the one posted by Elektra about the history of olsr), I believe the document that talks about the link quality extension is a little outdated, because it makes mention of MPR as being part of olsrd. Maybe the documentation has wrong information about olsrd. My question is: was the MPR concept completely banned from olsrd (I mean, when olsrd does not work just as specified by RFC 3626)? Since which version of olsrd was the MPR concept banned?
<br><br>Second: making a search in the message archive of the <a href="http://OLSR.ORG">OLSR.ORG</a> mailing lists I found the message at <a href="http://www.olsr.org/pipermail/olsr-users/2004-November/000317.html">http://www.olsr.org/pipermail/olsr-users/2004-November/000317.html
</a> that also mentions about MPRs. That e-mail refers about the 0.4.8 version of olsrd, which I believe is not too far from the current version. Where I could find documentation that really describes the technical details of olsrd in a broader view?
<br><br>Third: how does olsrd calculate the link quality values and the ETX for a given path? The e-mail I have mentioned earlier contradicts the Link Quality documentation of olsrd. For example, while the e-mail says the ETX value for a given path is the multiplication of the ETX value for every hop along the path, the Link Quality extension document says the total ETX value for a given path is the sum of the ETX calculated at every hop along the path. Needless to say that ETX values for each hop in the path are calculated far different.
<br><br>Once and again talking about MPRs, what was the heuristic used to calculate the MPR set in olsrd, when using the Link Quality extension? Have you seen at IEEE digital library papers that discuss new methods of calculating the MPR set? Some of them are quite interesting, I think, as they discuss ways of making nodes with good conectivity or low delay to their neighbors being selected as MPRs by the current node. The best proposal I have seen so far as the QOLSR and QOLSR+. Do you have any words about it? Or could someone even point me the thread in which this subject was previously discussed in the list.
<br><br>Thanks in advance,<br><br><div><span class="gmail_quote">On 12/27/06, <b class="gmail_sendername">Andreas Třnnesen</b> <<a href="mailto:andreto@olsr.org">andreto@olsr.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Without having read the draft, I belive OLSRv2 is still based on<br>the concept of MPRs. Real life experience has shown that this<br>concept is not a very successfully one. As olsrd has moved along<br>from a more or less theoretical test implementation to a real-life
<br>experiment it has become something very different from RFC3626.<br><br>So even though OLSRv2 is definetly something to have an eye on,<br>I do not believe it will be implemented as part of olsrd. Read more<br>about the real-life experiments and the extensions needed for
<br>olsrd to work properly in real-life meshes at:<br><a href="https://www.open-mesh.net/optimized-link-state-routing-deamon/olsr-story.txt/view">https://www.open-mesh.net/optimized-link-state-routing-deamon/olsr-story.txt/view
</a><br><br>My guess is that B.A.T.M.A.N. will have taken over for olsrd by<br>the time OLSRv2 reaches RFC :-)<br><br>Anyway, that is my $0.02...<br><br>- Andreas<br><br>Zeus Gómez Marmolejo wrote:<br>> Hi,<br>><br>
> Although it's still an IETF draft -not an RFC-, OLSR version 2 is<br>> already submitted. Should it be considered to be included in olsrd?!<br>> It has some major improvements about the network-wide broadcast of
<br>> link-state information and mantaining partial link-state information<br>> on each node.<br>><br>> I think you should have an eye on the draft:<br>><br>> <a href="http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-02.txt">
http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-02.txt</a><br>><br>> What do you think about??<br>><br>><br>><br>> Zeus.<br>><br>> _______________________________________________<br>> olsr-dev mailing list
<br>> <a href="mailto:olsr-dev@olsr.org">olsr-dev@olsr.org</a><br>> <a href="https://www.olsr.org/mailman/listinfo/olsr-dev">https://www.olsr.org/mailman/listinfo/olsr-dev</a><br><br><br>_______________________________________________
<br>olsr-dev mailing list<br><a href="mailto:olsr-dev@olsr.org">olsr-dev@olsr.org</a><br><a href="https://www.olsr.org/mailman/listinfo/olsr-dev">https://www.olsr.org/mailman/listinfo/olsr-dev</a><br></blockquote></div><br>
<br clear="all"><br>-- <br>Weverton Luis da Costa Cordeiro <br>Undergraduating in Computer Science <br>Federal University of Para - UFPA <br><a href="http://www.labes.ufpa.br/weverton">http://www.labes.ufpa.br/weverton</a>