Hello Vicky,
I'll just put all my follow-up here...
1) Although I prefer mentioning precursors as an optional feature in the
relevant part of the main text, I would be somewhat O.K. with removing
the mention of it until later. However, might I suggest that we wait
until anyone complains about it?
Regarding the previous mention of this on the mailing list...
without going
into sordid details, please take my word that it was a specific
point on a
rather nasty vendetta.
2) Regarding the use of the MAC address: as mentioned in previous email,
it could be a burden on the forwarding engine of the router which
otherwise
has to do almost no bookkeeping other than statistics. Whether or
not the
MAC address is available depends on the operating system. Linux is no
problem at all. Windows does allow it, I am pretty sure, but not
as nice.
I reckon Apple would allow it because they use Unix but I'll have
to check.
Now, whether RFC 5444 allows it for control traffic is another
question.
I am guessing that they would hate it with a very special hatred.
If you want to write it up, perhaps "MAY" is the proper level of mandate...
Regards,
Charlie P.
On 4/30/2015 8:39 AM, Victoria Mercieca wrote:
Hi Charlie,
A quick update on this email thread:
* Should we even mention precursors in the main text if its anI think it makes sense to allow mention of optional features in
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.
the main body of the text.
Me too, but my question was based on a comment from the MANET list (and fair enough maybe they didn't pay attention as they read it, and I think some of the text has changed anyway), but we can make it really easy for a reader by removing this, and saying in the precursors section that we need to store the precursor list as part of the route entry.
1. How would you know which router forwarded traffic to you forSince all precursors are neighbors, it seems to me that saving the
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.
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.
The MAC idea sounds a bit ugly but it will work – as long as AODVv2 is allowed to see the MAC address of packets the router forwards. Do you think we are? And where would we document this requirement?
So for packets we forward, we could take a look at src MAC address, work out the router which is the precursor, and save that.
This idea would also fix my problem with RERR for undeliverable packet. We send the RERR unicast to the neighbour router which has MAC address matching the src MAC of the undeliverable packet.
Should I write this into the draft?
Kind regards,
Vicky.
Regards,
Charlie P.
