Welcome back Vicky,
Follow-up below...
On 5/7/2015 1:56 AM, Victoria Mercieca wrote:
On Thu, Apr 30, 2015 at 7:42 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
CP: Wouldn't the PktSource still be a data element even if it is an Address Block TLV?
VM: Yes, my mistake. We'd still have PktSource and AddressList as normal but in the RFC5444 section, the mapping is where it will be handled differently. Should I go ahead and do this?
CP: I agree with you that sending an RERR upon reception of an undeliverable data packet SHOULD inhibit sending of new RERR packets for a little while for the same PktSource/destination pair.
Should I add a sentence something like this?:
"In order to avoid flooding the network with RERR messages when a stream of packets to Unreachable Address arrives, an AODVv2 router SHOULD determine whether a RERR has recently been sent with the same unreachable address and PktSource, and avoid creating duplicate RERR messages. "
Do we need to define anything though, or leave it to implementations to decide the details?
CP: Generally, the reason for not multicasting is to avoid bothering otherwise
* If we send the RERR to the next hop on our route to
PktSource, how can we be sure this is the route
PktSource used to forward the packet? (See also the
email on precursors - the following scenario is
duplicated in that email in the context of precursors)
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 which it cannot forward to
destination, C sends a RERR to B using the PktSource
data element.
However, the packet might have come via D - the source
could be using the route via EDC. If the RERR goes to
B, B might regenerate it to A (or it might not be
regenerated at all), then A might regenerate it to
source (or not regenerate at all), and if it reaches
the source, the source will say "thats not my next
hop, I don't care" and ignore it. It will carry on
sending packets via E and D, and C will again 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 used the
route via B and C to reach the destination. If the
RERR goes back a different way to the route PktSource
is using, it will get ignored, if not at an
intermediate node, it will get ignored by source.
I have not heard of this being a problem. However, if it
needs to be prevented,
we could say that the second RERR from missing route to a
destination should
be multicast.
Regards,
Charlie P.
Why dont we just multicast it anyway? By multicasting from the
start, we avoid wasting messages (first the one C sends to B,
then the one B might send to A, then the one A might send to
PktSource), and we KNOW that PktSource will get it.And if our
route isnt used by a router that receives our RERR, it wont
regenerate it, simple. It only goes as far as it needs to.
Alternatively, Charlie's MAC address idea from the email about
precursors will work.
quiescent neighbors. But this could be a selectable behavior. Notably, when
PktSource is included, a lot of neighbors might end up forwarding separate
RERR messages back to PktSource, so multicast could be burdensome.
CP: Storing MAC addresses during packet forwarding might have a big impact
on throughput. Stan would know better, but I think that routers hate doing
that sort of thing.
VM: The RERR needs to come from PktSource's next hop on the route to unreachable address. Any other RERRs wont result in the route being deleted on PktSource. The way to ensure that is to multicast. HOWEVER, I've just thought of another solution: We could add in a test that if we receive a RERR and we are PktSource (or it is one of our Router Clients), we should process the route and delete our route to that address, even if the message isn't from our next hop. Would that be acceptable? Could be mis-used though, an attacker could stop PktSource sending traffic by sending a malicious RERR with a PktSource value, knowing that the RERR would cause the contained route to be deleted, cutting off its communication to the destination.
