Subject: [manet] #5: Reorganizing the route table entry timeout management

From: "manet issue tracker" <[email-masked]>
Date: Mon, 05 Nov 2012 04:52:29 -0000

#5: Reorganizing the route table entry timeout management

 The current set of route timeouts and concepts is confusing.  Instead, one
 can view a route table entry as having a normal lifetime progressing
 through the following stages: Active --> Idle --> Expired --> Expunged.
 Alternatively a route can be prematurely invalidated if one of its path
 components breaks (i.e., the link to a next hop breaks).  By reorganizing
 route lifetime information in this way, a much simpler description can be
 given.  The following proposed text should make this approach clearer.
 Instead of previous manifest constants for various timeout information,
 the new approach only requires ACTIVE_INTERVAL, MAX_IDLETIME, and
 MAX_SEQNUM_LIFETIME.  The following text has been (provisionally) added to
 Section 4.1.

 ========================================================================

    A route table entry (i.e., a route) may be in one of the following
    states:

    Active
       An Active route is in current use for forwarding packets

    Idle
       An Idle route can be used for forwarding packets, even though it
       is not in current use

    Expired
       After a route has been idle for too long, it expires, and may no
       longer be used for forwarding packets

    Broken
       A route marked as Broken cannot be used for forwarding packets but
       still has valid destination sequence number information.

    The route's state determines the operations that can be performed on
    the route table entry.  During use, an Active route is maintained
    continuously by AODVv2 and is considered to remain active as long as
    it is used at least once every ACTIVE_INTERVAL.  When a route is no
    longer Active, it becomes an Idle route.  After a route remains Idle
    for MAX_IDLETIME, it becomes an Expired route; after that, the route
    is not used for forwarding, but the sequence number information is
    maintained until the destination sequence number has had no updates
    for MAX_SEQNUM_LIFETIME.  After MAX_SEQNUM_LIFETIME, old sequence
    number information is considered no longer valuable and the route is
    expunged.

    MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2
    router MUST NOT transmit any routing messages.  Thus, if all other
    AODVv2 routers expunge routes to the rebooted router after that time
    interval, the rebooted AODVv2 router's sequence number will not be
    considered stale by any other AODVv2 router in the MANET.

    When the link to a route's next hop is broken, the route is in the
    Broken state, and it may no longer be used.

 ========================================================================

 Note that if (ACTIVE_INTERVAL + MAX_IDLETIME) == MAX_SEQNUM_LIFETIME,
 then a route has to be expunged as soon as it has been idle too long.
 This has little negative impact on the base protocol but may eliminate the
 possibility for some optional features related to route repair.

-- 
--------------------------------+-----------------------------
 Reporter:  charliep@…          |      Owner:  Charlie Perkins
     Type:  defect              |     Status:  new
 Priority:  major               |  Milestone:
Component:  dymo                |    Version:
 Severity:  Active WG Document  |   Keywords:  route timeouts
--------------------------------+-----------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/5>
manet <http://tools.ietf.org/manet/>

---

From: "manet issue tracker" <[email-masked]>
Date: Mon, 05 Nov 2012 18:37:50 -0000

Comment (by charliep@…):

 It is possible for incoming !RteMsg information to supply a VALIDITY_TIME
 for the information, which has the effect of creating additional state for
 the relevant route table entry.   VALIDITY_TIME amounts to a
 respecification of (ACTIVE_INTERVAL + MAX_IDLETIME) for the routing
 information, in that a route MUST be expired after the route table entry
 was maintained for the VALIDITY_TIME.  A proposal is to do this by adding
 a "validity_expiration" field to the route table entry.

-- 
--------------------------------+------------------------------
 Reporter:  charliep@…          |       Owner:  Charlie Perkins
     Type:  defect              |      Status:  new
 Priority:  major               |   Milestone:
Component:  dymo                |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:  route timeouts      |
--------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/5#comment:1>
manet <http://tools.ietf.org/manet/>