Subject: RE:[manet] Clarification on RFC 3561 (current time & updating route lifetime)

From: Ian Chakeres <[email-masked]>
Date: Mon, 25 Aug 2003 11:12:55 -0700

The draft is correct.  It should be current time and not
ExistingLifetime. ExistingLifetime refers to an absolute time.

Regarding your idea to change the lifetime update of active routes,
this may increase performance under certain conditions but can have an
equal negative impact under other conditions.  Personally I prefer
updating the lifetime for each packet.  I believe any minor
performance increase would be offset by a more complex design and
implementation. 

Ian Chakeres

>Koojana Kuladinithi wrote:
>Hello Ian,
>
>I would appreciate if you can clarify the following
>to me.
>
>In the following formula in Section 6.5,
>
>  MinimalLifetime =    (current time + 2*NET_TRAVERSAL_TIME -
>                           2*HopCount*NODE_TRAVERSAL_TIME).
>
>What does current time refer to, in this formula? In other
>places, current time refers to the current clock time. If we
>assume that here, MinimalLifeTime will an absolute time.
>
>Shouldn't "current time" be "ExistingLifetime" ?
>
>
>--------------------------------------------------
>
>This is just an idea, which you might have discussed previously.
>
>According to the RFC 3561, each time a route is used to forward a data
>packet, lifetime of the particular route should be extended.
>
>This, I believe is an overhead on the AODV protocol handler, as it has to
>perform updates for every packet that uses every route.
>
>Can this be done in the following way?
>
>When a route is used, the lifetime of the route is extended by
>ACTIVE_ROUTE_TIMEOUT.
>Once this is done, we stop updating lifetime for every packet using
>the route.  We setup a timer to get activated at X, after which we start
>again to check the route use.
>
>If a packet is received again, the route lifetime is updated and a timer is
>setup for X. Else, route expiry occurs.
>
>X = 75% of ExistingLifeTime
>
>Kind regards
>
>Koojana
>
>
>
>University of Bremen
>FB 1 - IKOM/ComNets
>Koojana Kuladinithi BSc, MSc
>Otto-Hahn-Allee NW 1
>28359 Bremen - Germany
>
>Tel.: +49 421 218 8264, Fax: +49 421 218 3601, Mobile: +49 160 2690070
>Email: [email-masked]  
>[email-masked] 
>
> 
>
>
>
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/manet

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

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Mon, 25 Aug 2003 10:24:11 +0200

Hello Ian,

Kind regards

Koojana

University of Bremen
FB 1 - IKOM/ComNets

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Tue, 30 Sep 2003 16:12:14 +0200

Hi Ian

Section 6.2 pf RFC 3561 says following. 
When an ordinary (i.e. non-AODV) packet is received, if routes exist, then
they should be updated (lifetime) to destination next hop to destination
Source.
 
If destination is equal to next hop, then the lifetime of the 
destination updates as long as the data packets go.

But, if we use Hello messages to detect the link break to next hop, in the
above case, we found that the lifetime of the destination never expires due
to incomming packets and we can"t detect the link break using Hello
messages.

Has this problem been addressed in the RFC or 
Should we update route lifetime of destination that is equal to the next
hop, solely due to Hello messages?

Kind regards

Koojana

University of Bremen
FB 1 - IKOM/ComNets

---

From: Ian Chakeres <[email-masked]>
Date: Tue, 30 Sep 2003 12:51:48 -0700

There must be separate hello timer associated with each neighbor. The
lifetime field in the routing table cannot be used to indicated loss
of connectivity to a neighbor. See manet and aodvimpl mailing list
archives, I believe this was discussed.

Here is an example, consider the network A-B-C where A is sending
packets to C. B, must receive a hello message or other message from C
within hello_interval*allowed_hello_loss. If B does not, it will
detect a loss of connectivity to C.

The link connectivity between C and B is independent the lifetime
field. The lifetime is influenced by A sending packets to C through B.

I hope this helps.
Ian Chakeres