Hi Charlie,
A quick update on this email thread:
fair enough maybe they didn't pay attention as they read it, and I think
- Should we even mention precursors in the main text if its an
optional feature? It is only mentioned at part of the route table entry but
we can easily remove this, and in the Precursors section state that the
list would be part of the route table entry.
I think it makes sense to allow mention of optional features in the main
body of the text.
Me too, but my question was based on a comment from the MANET list (and
1. How would you know which router forwarded traffic to you for a
particular destination? You'd only know the packet source and the interface
it came in on.
Option 1: you could save PktSource as the precursor. If the route then
broke, look up the route to PktSource, and if there is one, send the RERR
to the next hop toward PktSource. If there was no route, you'd still have
to multicast the RERR.
Option 2: look up the route to PktSource and (if it exists) save the next
hop as a precursor. If the route breaks, send the RERR to the precursor
address. If our next hop to PktSource changed before the RERR was sent,
this might go to the wrong router. Also if there was no route to PktSource,
we cant save a precursor, so would we assume no RERR was needed?
I think Option 1 is better.
However, if the next hop we send the RERR to doesn't use us as a next hop
to the destination, they will just ignore the RERR.
Consider:
source -----> A ---------> B ----------> C ----------> destination
| | ^
| | |
V V |
E --------> D -------------------------|
C's next hop to the source is B. When C receives a packet from source,
C saves B as a precursor. However, the packet might have come via D.
If C's route to the source changes to use next hop D, which router
should be told when the route to the destination breaks at C?
The source could be using the route via EDC. If the RERR goes to B, B
might regenerate it to A, then A might regenerate it to source, but the
source will say "thats not my next hop, I don't care". It will carry on
sending packets, C will say "I've got no route, send a RERR to PktSource"
(and the same thing happens again).
Either way, just because C's next hop to PktSource is B, doesnt
necessarily mean that PktSource uses the route via B and C to the
destination. If the RERR goes back a different way to the route PktSource
is using, it will ignore the RERR. This affects both the use of precursors,
and the unicast RERR in response to a packet that cant be forwarded.
Since all precursors are neighbors, it seems to me that saving the next hop
as the precursor is more consistent.
There is a way to solve this problem, but until it becomes an actual
problem
instead of a theoretical problem, we might be better of to just let it be.
If, however, that's not acceptable, then we should put the MAC address into
the Neighbor List, and then check every data packet coming through to see
if it comes from a MAC address in our Neighbor List. That's not terrible,
but
it is work.
I'm not happy with “letting it be” until it becomes a problem.
Regards,
Charlie P.
