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

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 08 Feb 2013 15:22:20 -0800

Hello folks,

The route table timeout issue and proposed resolution has been incorporated
in the most recent revisions for the AODVv2 specification.  If the new 
timeout
structure and definitions are satisfactory, the AODVv2 editing team will
consider closing issue #5.  Please let us know if there is any objection to
closing the issue.

Regards,
Charlie P.

On 11/4/2012 8:52 PM, manet issue tracker wrote:
> #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.
>

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 9 Feb 2013 02:00:50 +0100

+1

I have no objection.

AB

On 2/9/13, Charles E. Perkins <[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 11 Feb 2013 09:03:21 +0100

I advise not to close any related issue until Chair makes input. We
still not received the email of chair regarding editing team of the
reactive protocol. IMO, it is reasonable to close WG-issues only after
receiving the Chair's advises. Otherwise why the chair is a chair, I
think the chair helps to close such WG issues. The co-chair mentioned
to continue WG discuss or I may understand to open issues but not
understand to close issues,

If I mistaken or missed something please advise,

AB