Hi Vicky,
Am 23.06.2015 um 13:45 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte,
If A is sending a RREQ on behalf of OrigAddr, it will include hopcount metric
= 0 I thought. So when B gets that message, it sees zero, then adds Cost(L)
which is 1, so it stores route to OrigAddr with cost 1. It would then
advertise the cost of 1, so a router C (one hop further down the line) would
see advertised metric = 1, and would add cost of link from C to B to get
route cost of 2.
So basically when sending a RREQ for a router client, you'd set metric to
zero.
Regards,
Vicky.
On Tue, Jun 23, 2015 at 12:40 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi all,
yet again, I'm not sure if I'm being stupid right now, but I think I've found
a misimplementation on my part and was wondering if it's just me or if we
should change the wording.. maybe one of you has the time to take a look:
Section 6.5. Processing Received Route Information says:
o AdvRte.Cost := AdvRte.Metric + Cost(L) using the cost function
associated with the route's metric type, where L is the link from
the advertising router
and then, section 6.5.2. Applying Route Updates says:
o Route.Metric := AdvRte.Cost
This (I think) has led me to implement my route table in a way that when I
have (very simplified) nodes A <-> B <-> ..., B's route table will say the
(hop count) metric for its connection to A is actually 2, since it takes the
Hop Count it learned from the RREQ and then adds another hop (namely Cost(L))
onto it. This doesn't seem right to me; should I get another coffee or is
this an issue (i.e. if B's route table should have a metric of 1 for the
route towards A)?
Regards,
Lotte
