Subject: Re: AODV draft issue (RERR)

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 27 Jul 2001 11:57:21 +0300

Hi everybody ;)

Let's see.

"Elizabeth M. Royer" wrote:
> Manel and Mahesh,
> 
> So you are proposing that, when a node receives a RERR, that it
> invalidates its route entry for that destination if both the source
> of the RERR is the next hop on that route, AND the dest seqno in 
> the RERR for that dest is >= that which the node has for the dest

Correct me if I'm wrong, but I thing it should be > and not >=

> in its route table, correct?  So we would have to add the second
> condition to the draft.  And this will prevent the re-ordering of
> control packets at the MAC layer that Mahesh pointed out.
> 
> I'm not yet quite convinced about the original problem, however.
> If a node reboots, it loses its dest. seqnos.  If it receives a data
> packet for some destination for which it does not have a route,
> it sends a RERR.  But there is still the question of what seqno
> to put in that RERR for the destination, so that the upstream node
> will take note of the RERR and stop using that route.  Suggestions
> for how to handle this?  The rebooted node will not have a way to
> obtain the current seqno for that destination.  
> 
> Elizabeth

And then:

"ext Samir R. Das" wrote:
> 
> OK. We can use a MAXINT like value and reserve it for this case. That
> will
> not require any format changes.
> 
> Somehow I believe all these are of theoretical interest. Realistically,
> I
> don't think any node will hold valid routes through a crashed node long
> enough for it to come back up and then act like a troublemaker. For that
> to
> happen nodes have to crash/reboot within a few seconds ..
> 
> Finally, as somebody pointed out here, if DELETE_PERIOD is properly set,
> we
> will not even need this RERR. The rebooted node can be just silent. This
> is
> by the definition of DELETE_PERIOD. However, I guess we have that extra
> caution, as the design of DELETE_PERIOD itself is link-layer specific
> and is
> quite troublesome if the link is asymmetric/unidirectional. Then again
> AODV
> will not use such a link.

Acording to the draft a node that has rebooted does not respond to aodv
packets, but it does respond to data packets with RERR.

And the default value in the draft of DELETE_PERIOD is 15 secs,
but depending on the scenario it could be more. Nodes might reboot
quite fast (not like my laptop).

Anyway, we should know what to do if this situation happens.
(even if it is unlikely  to happen)

Before, I sugested to do nothing, but after thinking in the situation
of a node that has just rebooted and earing all the comments,
I'm for the 'MAXINT like' approach.

Regards,

	Manel Guerrero

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 27 Jul 2001 11:57:21 +0300

Hi everybody ;)

Let's see.

And then:

Regards,

	Manel Guerrero