Subject: [manet] AODV: Lifetime of reverse routes...

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 01:59:44 +0200

Hello

The AODV draft say (section 6.2) that the next hop along the reverse
path of a route should be updated when a data packet is forwarded (along
with the destination and next hop of the forward route). However, since
it is impossible to tell from the packet which node the packet is
received from, without keeping track of MAC-addresses, one must check
the reverse route entry for its next hop. 

The problem is that the draft does not mention anything about updating
the destination of the reverse route (or did I miss this?), so if the
communication is one way, the reverse route entry eventually is deleted
and the information about the reverse route's next hop is lost.
Therefore it is also impossible to update the lifetime of the next hop
along the reverse route when data packets along the forward route are
received.

The result is that the next hop along the reverse route also gets
deleted. This may hinder forwarding of RERRs and the source generating
the data is never informed when the route breaks.

The solution is of course to update the lifetime of the destination of
the reverse route too, so that the information about its next hop is
kept while the forward route is active.

Comments?

Best Regards

Erik Nordström

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Samir R. Das" <[email-masked]>
Date: Wed, 5 Jun 2002 20:37:11 -0400

Hi Erik,

I somehow do not follow your arguments. 

The source IP address in a data packet can be used as the destination of
the reverse path. The next hop for this routing entry is the next hop
towards the destination of the reverse path. 

I guess here the language in the draft should be changed to remove the
words "previous hop." You are right in that it is not "directly" known
in the routing layer.

Also, refreshing the reverse path is an optimization. Even if the
reverse path is deleted, it does not hinder the RERR propagation.
Typically, RERRs are broadcast or even if unicast, the precursor list is
used to get the next hop for RERR.

Samir

>  -----Original Message-----
>  From: [email-masked] [mailto:manet-
>  [email-masked]] On Behalf Of Erik Nordström
>  Sent: Wednesday, June 05, 2002 8:00 PM
>  To: MANET LIST
>  Cc: AODV LIST
>  Subject: [manet] AODV: Lifetime of reverse routes...
>  
>  Hello
>

---

From: "Samir R. Das" <[email-masked]>
Date: Wed, 5 Jun 2002 20:37:11 -0400

Hi Erik,

Samir

---

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 02:49:15 +0200

> I somehow do not follow your arguments. 

I knew this would be a problem... :-) 

> towards the destination of the reverse path. 

Yes, but my point is that if the routing entry of the reverse route
destination does not have its lifetime refreshed, the reverse next hop
is lost. The draft does not mention that the destination of the reverse
path should be refreshed when forwarding packets on the forward route.

> used to get the next hop for RERR.

The propagation of RERRs is broken since there is no way to keep track
of next hops along the reverse route if the routing entry of the reverse
route is not refreshed, as stated above. Therefore *both* the reverse
path routing entry and the next hop entry along that route MUST be
refreshed, right?

/Erik

> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> Aodvimpl-public mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/aodvimpl-public

---

From: "Samir R. Das" <[email-masked]>
Date: Wed, 5 Jun 2002 21:04:09 -0400

>  Sent: Wednesday, June 05, 2002 8:49 PM
>  To: Samir R. Das
>  Cc: 'Charles E. Perkins'; Elizabeth M. Belding-
>  Royer; 'AODV LIST'; 'MANET LIST'
>  Subject: Re: [Aodvimpl] RE: [manet] AODV: Lifetime
>  of reverse routes...
>  

OK. I guess the language can be made more specific here  ..

Regarding your comment on RERR below, I do not see why you need a valid
reverse path to propagate RERR! True, RERR goes in the reverse
direction, but it does not need to have a valid reverse path entry. It
is either simply broadcast or it may be unicast to node(s) in the
appropriate precursor list(s). Why do you care for the reverse path? 
 
>  > >  The AODV draft say (section 6.2) that the next
>  hop
>  > >  along the reverse
>  > >  path of a route should be updated when a data
>  packet
>  > >  is forwarded (along
>  > >  with the destination and next hop of the
>  forward
>  > >  route). However, since
>  > >  it is impossible to tell from the packet which
>  node
>  > >  the packet is
>  > >  the destination of the reverse route (or did I
>  miss
>  > >  this?), so if the
>  > >  communication is one way, the reverse route
>  entry
>  > >  eventually is deleted
>  > >  and the information about the reverse route's
>  next
>  > >  hop is lost.
>  > >  along the reverse route when data packets along
>  the
>  > >  forward route are
>  > >  received.
>  > >
>  > >  The result is that the next hop along the
>  reverse
>  > >  route also gets
>  > >  deleted. This may hinder forwarding of RERRs
>  and the
>  > >  source generating
>  > >  The solution is of course to update the
>  lifetime of
>  > >  the destination of
>  > >  the reverse route too, so that the information
>  about
>  > >  its next hop is
>  > August 25-28 in Las Vegas --
>  http://devcon.sprintpcs.com/adp/index.cfm
>  >

---

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 03:22:19 +0200

> appropriate precursor list(s). Why do you care for the reverse path? 

Because the reverse path contains the necessary information to keep the
next hop in that direction refreshed. If the next hop of the reverse
path times out, it is also removed from *all* precursor lists! If no
precursors exists we will not send a RERR...

It is true that the reverse path is not needed if you broadcast the
RERR, but if you only have one precursor on the (broken) forward route,
the RERR should be unicasted and then the next hop of the reverse path
is needed, right?

Are we in agreement that the next hop of the reverse path is needed if
we are to unicast the RERR? (Keep in mind if it is removed, it is also
removed from all precursor lists). In that case the reverse next hop
must be refreshed (which is also stated in the draft).

Then tell me, when we forward a data packet on the forward route, how do
you figure out the previous hop of that message? - You check the source
IP, look it up in the routing table and check the next hop in that
entry. But how do you do that if that routing table entry does not
exist??? Conclusion: We must also refresh the reverse path entry to keep
it from expiring.

/Erik

---

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 03:22:19 +0200

/Erik

---

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 02:49:15 +0200

/Erik

---

From: "Samir R. Das" <[email-masked]>
Date: Wed, 5 Jun 2002 21:04:09 -0400

---

From: "Samir R. Das" <[email-masked]>
Date: Thu, 6 Jun 2002 01:03:15 -0400

Erik,

I was trying to find a language in the draft that suggests
that when a next hop route expires that next hop is also
removed from all precursor lists. Where did you find this?

Also, all these are moot anyways as reverse routes
can easily be refreshed as you pointed out. I think we meant this
except that the draft language was not as specific ..

Samir

---

From: "Samir R. Das" <[email-masked]>
Date: Thu, 6 Jun 2002 01:03:15 -0400

Erik,

Samir

---

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 11:25:05 +0200

Hi Samir,

comments below:

> removed from all precursor lists. Where did you find this?

You appear to be correct in that this is not specified in draft 10, but
it was in draft 9 (section 8.11 last paragraph). This seem to be a
subtle change which I have missed. Keeping (potentially stale
precursors) will solve the problem with with RERRs mentioned earlier.

However, I still maintain that you must refresh the reverse route to be
able to refresh the next hop of the reverse route.

> except that the draft language was not as specific ..

As I am implementing AODV, I am not really interested in what you meant
when you wrote the draft, but what the draft actually say in its current
form. It is clear that the draft say (section 6.2) that only the next
hop of the reverse route should be refreshed when forwarding data
packets on the forward route.

I just want to know if I am correct in my analysis that the reverse
route entry must also be refreshed, so that I can create a draft
compliant AODV implementation? If this is the case, I strongly believe
this should be stated in the draft.

Best Regards

Erik

---

From: Erik Nordström <[email-masked]>
Date: 06 Jun 2002 11:25:05 +0200

Hi Samir,

comments below:

Best Regards

Erik