[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 701) ND neighbor cache states.
From:       Matt Thomas <matt () lkg ! dec ! com>
Date:       1995-09-26 16:47:37
[Download RAW message or body]


As a result of implementing Neighbor Discovery and after exchanging
email with Francis Dupont, I wish to propose the following change to
Neighbor Discovery states:

    The PROBE state (as it currently exists) in Neighbor Discovery
    should be split into two states, STALE and PROBE. 

Here are the current definitions of PROBE from
draft-ietf-ipngwg-discovery-02.txt:
   
   PROBE       The neighbor may be reachable, but the last explicit
   (page 17)   reachability confirmation was received long enough ago
               that verification is now actively sought.

   PROBE	More than ReachableTime milliseconds have elapsed since the
   (page 51)   last positive confirmation was received that the forward
               path was functioning properly.  Upon entering the PROBE
               state, no Neighbor Solicitation is sent.  However, a
               timer is set to expire DELAY_FIRST_PROBE_TIME seconds
               later, and a Neighbor Solicitation probe is sent if the
               entry is still in a PROBE state when the timer expires.
               Delaying the sending of the initial Neighbor Solicitation
               gives the upper layers additional time to provide
               reachability confirmation information.  After the initial
               delay, Neighbor Solicitations are retransmitted every
               RetransTimer milliseconds until a reachability
               confirmation is received.

These definitions (and especially the latter) are too complex.  In the
second definition, the first and second statements describe
different and possibly overlapping substates of the PROBE state.

Does one really enter the PROBE state after "More than ReachableTime
milliseconds..."?  Not according to the description of the NUD algorithm
on page 52:

    Unreachability detection changes a neighbor's state from REACHABLE to
    PROBE only on-demand, as a side effect of sending a data packet to that
    neighbor.  If no traffic is sent to a neighbor, no probes are sent
    either.  Note that an entry may technically no longer be in a REACHABLE
    state, but the condition need not be checked or acted upon until a
    packet is sent to the neighbor.


So let's define the idle period between being REACHABLE and instigating a
PROBE as STALE.  The new definitions could be:
   
       STALE	The contents of the neighbor cache entry may be valid, but
   		must be verified upon use.
   
       PROBE    The neighbor cache entry is undergoing verification of its
   		contents.

A possible scenario could be:
   
       ie.  REACHABLE -> STALE -> PROBE -> (deleted) -> INCOMPLETE

A related issue is that ND requires the neighbor cache entry go into PROBE
because of various events (such as receipt of neighbor advertisements).
Instead, the cache entry should became STALE and only go into PROBE when
the next transmission is done.

Matt Thomas                          Internet:   matt@lkg.dec.com
IPv6 Kernel Grunt                    WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]