The IP Over NBMA (ION) Archive

["Barbara A. Fox" <bfox@hjinc.com>]

This does seem to be a problem for SCSP.  The keys are going to be
reused.  If the server crashes, its DCS will send it alignment 
information that it originated (a CSAS with a cache key, CSA sequence
number, and its own OID).  It may or may not have the entry in its
local cache.  If it does, does it accept the received CSA sequence
number, increment it by one, and generate a new CSAS?  If the entry
isn't in its local cache, what does it do?

It seems that the solution Joel proposed for ATMARP SCSP needs to
be generalized for SCSP.  A lifetime field should be included in
the CSAS.  If a server receives a CSAS with itself as the originator
and the information does not correspond to its SCSP information (the
CSA sequence number is too big or SCSP doesn't recognize the cache key),
it should purge that CSA by incrementing the CSA sequence number and setting
the lifetime to zero.  This should not affect its local SCSP CSA sequence
number for that cache key (if it exists).

It seems that if SCSP generates the CSA sequence number, it
needs to include a lifetime.  Is that correct?  

I do realize that this is not a solution to the ATMARP SCSP problem.
  
Barbara

At 10:38 AM 4/23/97 -0400, Colin Verrilli wrote:
>
>3. On page 24
>   Cache Key
>     This is a database lookup key that uniquely identifies a piece of
>     data which the originator of a CSA Record wishes to synchronize
>     with its peers for a given "Protocol ID/Server Group ID" pair.
>     This key will generally be a small opaque byte string which SCSP
>     will associate with a given piece of data in a cache.  Thus, for
>     example, an originator might assign a particular 4 byte string to
>     the binding of an IP address with that of an ATM address.
>     Generally speaking, the originating server of a CSA record is
>     responsible for generating a Cache Key for every element of data
>     that the the given server originates and which the server wishes to
>     synchronize with its peers in the SG.
>
>Should we address the key reuse problem? If a server goes down and comes
>back, it's old information will be floating around the server group. If
>the server starts reusing old keys, things could get messy.