Documented the LinkQualityMult directive.
[olsrd.git] / README-Link-Quality.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <HTML>
3   <HEAD>
4     <TITLE>olsrd Link Quality Extensions</TITLE>
5
6     <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
7
8     <STYLE TYPE="text/css">
9       body {
10         font-family: verdana,arial,sans-serif;
11         font-size: 10pt;
12         background-color: #ffffff;
13         color: #000000;
14       }
15
16       :link { color: #123e80 }
17       :visited { color: #123e80 }
18       :active { color: #123e80 }
19     </STYLE>
20   </HEAD>
21
22   <BODY>
23     <H2>olsrd Link Quality Extensions</H2>
24
25     <P>
26       $Id: README-Link-Quality.html,v 1.2 2005/02/15 18:19:36 tlopatic Exp $
27     </P>
28
29     <H3>Credits</H3>
30
31     <P>
32       The way in which the ETX metric is applied to OLSR owes its
33       existence to ideas conceived by the wonderful folks at
34       <A HREF="http://www.c-base.org">c-base</A>
35       and
36       <A HREF="http://www.freifunk.net">freifunk.net</A>.
37       Any implementation bugs are solely Thomas's fault, though.
38     </P>
39
40     <P>
41       Guys, also thanks a lot for your hospitality, for your valuable
42       input, for being brave enough to test early releases of olsrd,
43       for supplying a great testbed in Berlin, and for being
44       you!
45     </P>
46
47     <H3>Changes</H3>
48
49     <UL>
50       <LI>
51         <P>
52           0.4.9 - Documented the <EM>LinkQualityMult</EM>
53           configuration directive.
54         </P>
55       </LI>
56     </UL>
57       
58     <H3>Theory</H3>
59
60     <P>
61       Release 0.4.8 of olsrd offers an experimental implementation of
62       an ETX-like metric. When calculating a routing table for us,
63       pure RFC-compliant OLSR simply minimizes the number of hops
64       between ourselves and the other nodes in the MANET, even if this
65       means that a route via a single very bad link will be preferred
66       to a route via two excellent links, although the latter would
67       probably have been the better choice.
68     </P>
69
70     <P>
71       To solve this problem, we have to teach olsrd how to tell good
72       links from bad links. We have done so by measuring the packet
73       loss for OLSR packets that we receive from our neighbors. As we
74       periodically receive HELLO messages from our neighbors (by
75       default every 2 seconds), we have enough packets to determine
76       the packet loss for packets that each of our neighbors sends to
77       us.
78     </P>
79
80     <P>
81       If, for example, 3 out of 10 packets are lost on their way from
82       our neighbor to ourselves, we have a packet loss of 3/10 = 0.3 =
83       30%. At the same time 7 of the 10 packets that the neighbor sent
84       went through. Hence, the probability for a successful packet
85       transmission from this neighbor to ourselves is 7/10 = 0.7 =
86       70%. This probability is what we call the <EM>Link
87       Quality</EM>. So the Link Quality says how good a given link
88       between a neighbor and ourselves is in the direction from the
89       neighbor to ourselves. It does so by saying how likely it is
90       that a packet that we send is successfully received by our
91       neighbor.
92     </P>
93
94     <P>
95       However, it is also important to know the quality of the link in
96       the opposite direction, i.e. how many of the packets that we
97       send out are received by each of our neighbors. So, we are not
98       only interested in the Link Quality of a given link, but also in
99       the corresponding neighbor's idea of the Link Quality. That's
100       what we call the <EM>Neighbor Link Quality</EM>. The Neighbor
101       Link Quality says how good a given link between a neighbor and
102       ourselves is in the direction from ourselves to the neighbor.
103     </P>
104
105     <P>
106       The Link Quality and the Neighbor Link Quality are values
107       between 0 and 1 or, which is equivalent, between 0 and
108       100%. They represent the probability that a packet that our
109       neighbor sends actually makes it to us (Link Quality) and that
110       a packet that we send actually makes it to our neighbor
111       (Neighbor Link Quality).
112     </P>
113
114     <P>
115       Let's now look at the probability for a successful packet round
116       trip, i.e. the probability that we successfully send a packet to
117       our neighbor and, on receiving it, our neighbor successfully
118       replies with a response packet. For a successful round trip both
119       packets must get through, the packet that we've sent and the
120       response packet that our neighbor has sent. So, the success
121       probability is NLQ x LQ, where NLQ is the Neighbor Link Quality
122       of the link and LQ is its link quality. For example, if we have
123       a NLQ of 60% and a LQ of 70%, the probability of a successful
124       round trip is 60% x 70% = 0.6 x 0.7 = 0.42 = 42%.
125     </P>
126
127     <P>
128       In wireless networks each recipient of a packet acknowledges
129       packet reception by sending back an acknowledgment packet to
130       the sender. So, when does a retransmission of a packet happen? 
131       It happens, if the sender does not receive an
132       acknowledgment. And in which cases does the sender not receive
133       an acknowledgment? If either the packet that it sent is lost or
134       if the corresponding acknowledgment packet is lost. So, what is
135       the probability for a retransmission to <EM>not</EM> take place? 
136       Well, as the sender's packet has to get through in one direction
137       and the recipient's acknowledgment has to get through in the
138       opposite direction, too, this is exactly the probability for a
139       successful packet round trip, i.e. NLQ x LQ.
140     </P>
141
142     <P>
143       We can now answer the question of how many transmission attempts
144       it will typically take to get a packet from us to a neighbor or
145       from the neighbor to us. It is 1 / (NLQ x LQ). So, in the above
146       case of NLQ x LQ = 42%, we expect on average 1 / 0.42 = 2.38
147       transmission attempts for a packet until it gets through.
148     </P>
149
150     <P>
151       Note that this number is valid for both directions of the link,
152       as in both cases we have to look at the probability for a
153       successful packet round trip. For packets that we send to our
154       neighbor, the packet goes from us to the neighbor and the
155       acknowledgment travels the other way around. For packets that
156       our neighbor sends to us, the packet goes from the neighbor to
157       us and the acknowledgment travels from us to the neighbor. In
158       both cases a packet is sent in each direction and retransmission
159       occurs if either packet is lost.
160     </P>
161
162     <P>
163       The value 1 / (NLQ x LQ) is called the <EM>Expected Transmission
164       Count</EM> or <EM>ETX</EM>. For those interested in a more
165       in-depth discussion, there's a scientific paper on it, just
166       goggle for "expected transmission count".
167     </P>
168
169     <P>
170       Let's assume that we have a route from ourselves via two nodes A
171       and B to a node C. What is the ETX for the total route, i.e. how
172       often is our packet retransmitted on its way from us to C? Well,
173       we know how many attempts we need on average to successfully
174       transmit a packet from us to A. Let's call this value ETX1. So,
175       we already have ETX1 attempts just to reach A. The packet would
176       then take an additional number of attempts to hop from A to
177       B. Let's call this second value ETX2. Finally, a further number
178       of attempts is required to hop from B to C. Let's call this
179       third value ETX3. Let's now have a look at the total number of
180       transmissions that have happened to get our packet from us to
181       C. This number is simply ETX1 + ETX2 + ETX3.
182     </P>
183
184     <H3>Protocol</H3>
185
186     <P>
187       In order to calculate the ETX for a link to a neighbor, we need
188       to know the neighbor's idea of the link quality, i.e. the NLQ,
189       as we can only determine the LQ ourselves, but we want to know
190       ETX = 1 / (NLQ * LQ). So the link quality extensions to olsrd
191       introduce a new kind of HELLO messages, which we call <EM>LQ
192       HELLO</EM> messages. For each link listed in such a message, the
193       originator of the messages also tells us the link quality. So,
194       each neighbor puts the LQ values that it has determined in the
195       message, which from our perspective are NLQ values. So, owing to
196       the LQ HELLOs we now have all the information to calculate the
197       ETX for each link between ourselves and one of our neighbors.
198     </P>
199
200     <P>
201       Let's again have a look at the total number of transmissions
202       required for a route that consists of more than one hop,
203       i.e. that is not a route to one of our neighbors. If we stick
204       with the above example, we know ETX1 from the LQ HELLOs. But how
205       do we learn ETX2 and ETX3? For this the link quality extensions
206       to olsrd introduce a new kind of TC messages. TC messages are
207       used in OLSR to tell the world, i.e. all other nodes in the
208       MANET, which neighbors we have. We have extended TC messages to
209       additionally carry information on how good the links to our
210       neighbors are. We call this extended variant of TCs,
211       analogously to LQ HELLOS, <EM>LQ TC</EM> messages.
212     </P>
213
214     <P>
215       So, with LQ HELLO messages we find out which neighbors we have
216       and how good our links to them are and with LQ TC messages, we
217       share this knowledge with all other nodes and all other nodes
218       share their knowledge with us.
219     </P>
220
221     <P>
222       In this way each node in the network ends up knowing which links
223       each other node in the MANET has and how good they are. Well,
224       actually, it's a bit more complex than that, because of an
225       optimization called multi-point relaying. But this is beyond the
226       scope of this introductory text.
227     </P>
228
229     <H3>Warning</H3>
230
231     <P>
232       LQ HELLO messages and LQ TC messages are not compatible with
233       RFC-compliant HELLO and TC messages. So make sure that you
234       either switch <EM>all</EM> nodes of your network to link quality
235       or <EM>none</EM> of your nodes. A mixed configuration will
236       probably result in an unpredictable mess.
237     </P>
238
239     <H3>Practice</H3>
240
241     <H4>New Configuration Parameters</H4>
242
243     <P>
244       Let's now have a look at how we would use the link quality
245       extensions. The configuration parameter that controls link
246       quality is <EM>LinkQualityLevel</EM>, as it sets the level to
247       which link quality is used, i.e. for which purposes olsrd looks
248       at the link quality information.
249     </P>
250     <UL>
251       <LI>
252         <P>
253           Setting this parameter to 0 disables the link quality
254           extensions. olsrd then works in exactly the same way as
255           before, i.e. it is RFC-compliant, uses HELLO and TC
256           messages, and calculates routes by minimizing the hop count.
257         </P>
258       </LI>
259       <LI>
260         <P>
261           Setting this parameter to 1 enable the link quality
262           extensions and tells olsrd to select MPRs based on the link
263           quality information. A neighbor is selected as an MPR, if
264           it has the best route to any 2-hop neighbor. Suppose that
265           ETX1 is the expected number of transmissions between us and
266           a neighbor N and that ETX2 is the expected number of
267           transmissions between N and a two-hop neighbor N2. For each
268           of our two-hop neighbors we then select the neighbor N as
269           an MPR that results in the lowest possible total ETX of ETX1
270           + ETX2.
271         </P>
272       </LI>
273       <LI>
274         <P>
275           Setting this parameter to 2 not only selects MPRs based on
276           the link quality but also considers link quality information
277           when calculating the routing table. For a given destination
278           node D we select the route that has the minimal total ETX of
279           ETX1 + ETX2 + ... + ETXn, where ETX1 is the expected number
280           of transmissions from us to our neighbor, ETX2 is the
281           expected number of transmissions from our neighbor to the
282           next node, and ETXn is the expected number of transmissions
283           from our destination's neighbor to the destination. This is
284           the recommended setting.
285         </P>
286       </LI>
287     </UL>
288
289     <P>
290       <B>IMPORTANT:</B> Remember to set <EM>all</EM> nodes of your
291       MANET to the same link quality level. Even if levels 2 and 3 use
292       the same kind of messages, i.e. LQ HELLOs and LQ TCs, they use a
293       different algorithm for calculating the routing table. This can
294       also mess up your routing!
295     </P>
296
297     <P>
298       The second configuration parameter related to link quality is
299       <EM>LinkQualityWinSize</EM>. When determining the packet loss of
300       the packets received from a neighbor, olsrd only looks at the
301       <EM>n</EM> most recent packets. By default <EM>n</EM> is set to
302       10, so olsrd looks at the ten most recent packets received (or
303       not received) from a neighbor and then determines the packet
304       loss. Let's assume that of the 10 packets we have received 7,
305       then we have missed 3, which corresponds to a packet loss of
306       3/10 = 0.3 = 30%. The corresponding Link Quality is 7/10 = 0.7 =
307       70%.
308     </P>
309
310     <P>
311       Let's have a look at what the default value means. Let's for the
312       moment only think of LQ HELLO messages and neglect other message
313       types. By default LQ HELLOs are sent every 2 seconds. So, we
314       calculate the packet loss over the past 20 seconds. So, changes
315       in the link quality are accounted for relatively fast. For
316       longer intervals just increase this value.
317     </P>
318
319     <P>
320       Version 0.4.9 supports a third configuration parameter,
321       <EM>LinkQualityMult</EM>. This is a per-interface parameter, so
322       it may only appear in an interface configuration block. This
323       parameter can be used to alter the LQ values that we announce,
324       which will then result in an altered ETX for links between us
325       and our neighbors - remember that ETX = 1 / (NLQ x LQ).
326     </P>
327
328     <P>
329       The idea is to enable us to make certain links that we have
330       artificially appear better or worse than they actually are. In
331       this way we can manually affect the routing decisions made by
332       the OLSR network.
333     </P>
334     
335     <P>
336       The <EM>LinkQualityMult</EM> parameter is followed by an IP
337       address and a number, the multiplier. The IP address specifies
338       the IP address of the neighbor interface address of the link
339       that we want to manipulate. The LQ values that we determine for
340       this link are then multiplied by the given multiplier.
341     </P>
342
343     <P>
344       If the word <EM>default</EM> is specified in lieu of an IP
345       address, then this multiplier applies to all links via the
346       interface that we're configuring. Note, however, that a
347       multiplier linked to a real IP address has priority over the
348       default multiplier. So, we're looking for the most specific
349       match.
350     </P>
351
352     <H4>Old Configuration Parameters</H4>
353
354     <P>
355       The link quality extensions do not work very well with
356       hysteresis. Hysteresis basically acts as a sort of barrier that
357       only links that are "good enough" can cross. If a link is too
358       flaky, hysteresis will make olsrd consider the link as
359       non-existent. So, this is a binary thing. Either a link is able
360       to cross the barrier, or it is not. There's nothing in
361       between. However, we want olsrd to consider <EM>every</EM> link
362       there is, without any barrier, because then we can leave it to
363       the link quality extensions to judge how good the link actually
364       is and how much we trust the link.
365     </P>
366
367     <P>
368       If a link with an ETX value of 50 is the only way of
369       reaching a node, then we want to use this link, as there is no
370       better way.
371     </P>
372
373     <P>
374       In addition, in contrast to only saying "good enough" or "not
375       good enough" like hysteresis, the link quality extensions offer
376       a much more detailed view of the world by saying something like
377       "75% good enough, 25% not good enough".
378     </P>
379
380     <P>
381       The second mechanism that could interfere with the link quality
382       extensions is the link detection scheme. By default, if olsrd
383       misses three (LQ) HELLO messages in a row from a neighbor, the
384       link is considered broken. However, we'd prefer the link to just
385       expose a lower quality. So, setting the HELLO validity time to
386       the HELLO interval multiplied by the link quality window size is
387       probably a good rule of thumb. In this way the link will be
388       removed not before the link quality extensions have had enough
389       time to gradually reduce the link quality to zero.
390     </P>
391
392     <H4>Sample Configuration</H4>
393
394     <P>
395       A minimal configuration that leaves everything at the default
396       and just makes the changes required for the link quality
397       extension to work properly could look as follows. Note the
398       <EM>ClearScreen</EM> directive that causes the screen to be
399       cleared before updated debug information is printed. This makes
400       the debug output more readable in many cases.
401     </P>
402
403     <PRE>
404 DebugLevel              2
405 ClearScreen             yes
406 LinkQualityLevel        2
407 LinkQualityWinSize      10
408 UseHysteresis           no
409
410 Interface "if03"
411 {
412   HelloInterval         2.0
413   HelloValidityTime     20.0
414 }
415     </PRE>
416
417     <P>
418       Let's assume that we would like to use the
419       <EM>LinkQualityMult</EM> directive to multiply the LQ value that
420       we report for the link between our local interface <EM>if03</EM>
421       and an interface of one of our neighbors that has an IP address
422       of 192.168.0.1. Say, we'd like to multiply the LQ value by
423       0.5. We would then simply add the following line to the
424       <EM>Interface</EM> section of the above configuration file.
425     </P>
426
427     <PRE>
428   LinkQualityMult 192.168.0.1 0.5
429     </PRE>
430
431     <P>
432       Suppose that we would further like to multiply the LQ values
433       that we report for all other links between our local interface
434       <EM>if03</EM> and a neighbor interface by 0.8. We would then
435       add a second, default <EM>LinkQualityMult</EM> statement and we
436       would end up with the following two lines.
437     </P>
438
439     <PRE>
440   LinkQualityMult 192.168.0.1 0.5
441   LinkQualityMult default 0.8
442     </PRE>
443
444     <P>
445       For the link to 192.168.0.1 the first line would have precedence
446       over the second (default) line and 0.5 would be used as the
447       multiplier. For all other links the default multiplier of 0.8
448       would be used, as there isn't any better match.
449     </P>
450
451     <H3>Debug Output</H3>
452     
453     <P>
454       0.4.8 also introduces significant changes in the debug
455       output. Let's have a look at what happens at debug level 2, which
456       is the recommended default for the link quality extensions.
457     </P>
458
459     <PRE>
460 --- 14:28:56.80 ---------------------------------------------------- LINKS
461
462 IP address       hyst   LQ     lost   total  NLQ    ETX
463 192.168.0.1      0.000  1.000  0      10     1.000  1.00
464     </PRE>
465
466     <P>
467       This table contains the links to our neighbors. It contains the
468       following columns.
469     </P>
470
471     <UL>
472       <LI>
473         <P>
474           <EM>IP address</EM> - the IP address of the interface via
475           which we have contact to the neighbor.
476         </P>
477       </LI>
478       <LI>
479         <P>
480           <EM>hyst</EM> - the current hysteresis value for this link.
481         </P>
482       </LI>
483       <LI>
484         <P>
485           <EM>LQ</EM> - the quality of the link determined at our
486           end. This is what we have previously called the Link
487           Quality.
488         </P>
489       </LI>
490       <LI>
491         <P>
492           <EM>lost</EM> - the number of lost packets among the
493           <EM>n</EM> packets most recently sent by our neighbor via
494           this link. <EM>n</EM> is the link quality window size.
495         </P>
496       </LI>
497       <LI>
498         <P>
499           <EM>total</EM> - the total number of packets received up to
500           now. This value starts at 0 immediately after a link has
501           come to life and then counts each packet. It is capped at
502           the link quality window size.
503         </P>
504       </LI>
505       <LI>
506         <P>
507           <EM>NLQ</EM> - this is our neighbor's view of the link
508           quality. Previously we have called this the Neighbor Link
509           Quality. This value is extracted from LQ HELLO messages
510           received from our neighbors. NB: If a neighbor stops
511           sending packets completely, we do not have any means of
512           updating this value. However, in this case the LQ value will
513           decrease and the link thus be detected as becoming worse.
514         </P>
515       </LI>
516       <LI>
517         <P>
518           <EM>ETX</EM> - this is the ETX for this link, i.e. 1 / (NLQ
519           x LQ).
520         </P>
521       </LI>
522     </UL>
523
524     <PRE>
525 --- 14:28:56.80 ------------------------------------------------ NEIGHBORS
526
527 IP address       LQ     NLQ    SYM   MPR   MPRS  will
528 10.0.0.6         1.000  1.000  YES   YES   NO    6
529     </PRE>
530
531     <P>
532       This table contains a list of all our neighbors. It is closely
533       related to the link table in that we are connected to a
534       neighbor via one or more links. The table has the following
535       columns.
536     </P>
537       
538     <UL>
539       <LI>
540         <P>
541           <EM>IP address</EM> - the main IP address of the neighbor.
542         </P>
543       </LI>
544       <LI>
545         <P>
546           <EM>LQ</EM> and <EM>NLQ</EM> - the LQ and NLQ values of the
547           best link that we have with this neighbor. (In
548           multi-interface configurations we can have more than one
549           link with a neighbor.)
550         </P>
551       </LI>
552       <LI>
553         <P>
554           <EM>SYM</EM> - this states whether the link to this
555           neighbor is considered symmetric by olsrd's link detection
556           mechanism.
557         </P>
558       </LI>
559       <LI>
560         <P>
561           <EM>MPR</EM> (multi-point relay) - this indicates whether we
562           have selected this neighbor to act as an MPR for us.
563         </P>
564       </LI>
565       <LI>
566         <P>
567           <EM>MPRS</EM> (multi-point relay selector) - this indicates
568           whether the neighbor node has selected us to act as an MPR
569           for it.
570         </P>
571       </LI>
572       <LI>
573         <P>
574           <EM>will</EM> - the neighbor's willingness.
575         </P>
576       </LI>
577     </UL>
578
579     <PRE>
580 --- 14:28:56.80 ------------------------------------------------- TOPOLOGY
581
582 Source IP addr   Dest IP addr     LQ     ILQ    ETX
583 10.0.0.6         192.168.0.2      1.000  1.000  1.00
584 10.0.0.6         10.0.0.5         1.000  1.000  1.00
585     </PRE>
586
587     <P>
588       This table displays the topology information that olsrd has
589       gathered from LQ TC messages. It states which nodes in the
590       network report links to which other nodes and which quality
591       these links have. So, it's olsrd's view of the world beyond its
592       immediate neighbor nodes, i.e. its view of the nodes that it
593       cannot reach directly. This table has the following columns.
594     </P>
595
596     <UL>
597       <LI>
598         <P>
599           <EM>Source IP addr</EM> - the node that reports a link.
600         </P>
601       </LI>
602       <LI>
603         <P>
604           <EM>Dest IP addr</EM> - the node to which the source node
605           reports the link.
606         </P>
607       </LI>
608       <LI>
609         <P>
610           <EM>LQ</EM> (link quality) - the quality of the link as
611           determined by the source node. For the source node this is
612           the Link Quality. For the destination node this is the
613           Neighbor Link Quality.
614         </P>
615       </LI>
616       <LI>
617         <P>
618           <EM>ILQ</EM> (inverse link quality) - the quality of the
619           link as determined by the destination node. For the source
620           node this is the Neighbor Link Quality. For the destination
621           node this is the Link Quality. We just did not want to name
622           it "NLQ", as we use NLQ only for the link quality reported
623           by our neighbors. But functionally this is equivalent to
624           the NLQ we know from the link and neighbor tables.
625         </P>
626       </LI>
627       <LI>
628         <P>
629           <EM>ETX</EM> - the ETX value for this link, calculated by
630           ETX = 1 / (ILQ x LQ).
631         </P>
632       </LI>
633     </UL>
634
635     <PRE>
636 --- 14:28:56.80 ------------------------------------------------- DIJKSTRA
637
638 10.0.0.6:1.00 (one-hop)
639 10.0.0.5:2.00 <- 10.0.0.6:1.00 (one-hop)
640     </PRE>
641
642     <P>
643       This table displays the best routes that olsrd could find for
644       each destination that it knows about. The leftmost IP address
645       given on each line is the destination of a route. The remaining
646       IP addresses in a line specify the nodes on the route between
647       ourselves and the destination address. Moving from the
648       destination address to the right, address by address, moves us
649       closer from the destination to ourselves, hop by hop.
650     </P>
651
652     <P>
653       In the above case we see routes to two nodes, 10.0.0.6 and
654       10.0.0.5. In the first line, there aren't any intermediate nodes
655       between us and the destination, the destination address is the
656       only IP address in this line. In the second line we have one
657       intermediate node, 10.0.0.6. So, the second line describes a
658       route to 10.0.0.5 via 10.0.0.6.
659     </P>
660
661     <P>
662       The number after the colon following an IP address in the table
663       is the total ETX of the route up to this IP address, i.e. the
664       sum of the ETX values of all hops between ourselves and this IP
665       address.
666     </P>
667
668     <P>
669       In the above example the first line represents a path with an
670       ETX value of 1.00 to 10.0.0.6. As we've seen in the neighbor
671       table above 10.0.0.6 is our neighbor, so the route to it
672       consists only of a single hop, which has an ETX of 1.00, hence
673       the 1.00 in this line.
674     </P>
675
676     <P>
677       In the second line, 10.0.0.5 is not a neighbor of ours. However,
678       10.0.0.6 is and from the topology table above we can tell that
679       10.0.0.6 reports a link to 10.0.0.5. So, we can reach 10.0.0.5
680       via 10.0.0.6. This is what this line says. Remember that each
681       line represents a route by first giving the IP address of the
682       destination (10.0.0.5) and that moving to the right means moving
683       towards ourselves until one of our (one-hop) neighbor is
684       reached. If we move from 10.0.0.5 to the right, we find
685       10.0.0.6, which is our (one-hop) neighbor. So we have a route.
686     </P>
687     
688     <P>
689       If we would like to know which path a packet takes that we send
690       to 10.0.0.5, we have to read the line backwards. We then see
691       that the packet first travels to our (one-hop) neighbor 10.0.0.6
692       via a link that has an ETX of 1.00 (which we can confirm by
693       looking at the neighbor table above). From there it is forwarded
694       to 10.0.0.5 via another link that also has an ETX of 1.00 (which
695       we can confirm by means of the topology table above), resulting
696       in a total ETX of 1.00 + 1.00 = 2.00, which is the number that
697       follows 10.0.0.5. Remember that the ETX value given for an IP
698       address is the cumulative ETX for the complete route up to this
699       IP address.
700     </P>
701
702     <P>
703       If olsrd is able to find a route between us and the destination,
704       the last IP address in the line is one of our neighbors. In this
705       case, "(one-hop)" is appended to the line to illustrate that the
706       last IP address is one of our (one-hop) neighbors. However,
707       let's assume that we've just switched on olsrd. In this case, it
708       does not know about all links in the network, yet, as it hasn't
709       received LQ TC messages from all nodes. So, it may know that a
710       node exists (as it has already received LQ TC messages from it)
711       but it does not necessarily know how to reach it (as it may not
712       have received LQ TC messages from nodes between it and
713       ourselves, yet). In this case the last IP address is the last
714       node that is reachable from the destination and the line ends
715       with the word "FAILED".
716     </P>
717
718     <P>
719       The same is true for neighbors to which we do not have a
720       symmetric link. We know that they're there, but we do not have a
721       link to them, hence olsrd cannot find a route, which results in
722       "FAILED".
723     </P>
724
725     <H3>Remarks</H3>
726
727     <P>
728       If you have any questions on using olsrd or if you would like to
729       know more about the link quality extension, it's probably best
730       to subscribe to the mailing lists and ask your question
731       there. Information on the mailing lists is available at
732       <A HREF="http://www.olsr.org">http://www.olsr.org</A>.
733     </P>
734
735   </BODY>
736 </HTML>