RFC 2334 (rfc2334) - Page 2 of 40
Server Cache Synchronization Protocol (SCSP)
Alternative Format: Original Text Document
RFC 2334 SCSP April 1998
still remains the problem of cache synchronization; i.e., when one
server becomes aware of a change in state of cache information then
that server must propagate the knowledge of the change in state to
all servers which are actively mirroring that state information.
Further, this must be done in a timely fashion without putting undue
resource strains on the servers. Assuming that the state information
kept in the server cache is the state of clients of the server, then
in order to minimize the burden placed upon the client it is also
highly desirable that clients need not have complete knowledge of all
servers which they may use. However, any mechanism for
synchronization should not preclude a client from having access to
several (or all) servers. Of course, any solution must be reasonably
scalable, capable of using some auto-configuration service, and lend
itself to a wide range of authentication methodologies.
This document describes the Server Cache Synchronization Protocol
(SCSP). SCSP solves the generalized server synchronization/cache-
replication problem while addressing the issues described above.
SCSP synchronizes caches (or a portion of the caches) of a set of
server entities of a particular protocol which are bound to a Server
Group (SG) through some means (e.g., all NHRP servers belonging to a
Logical IP Subnet (LIS)[1]). The client/server protocol which a
particular server uses is identified by a Protocol ID (PID). SGs are
identified by an ID which, not surprisingly, is called a SGID. Note,
therefore, that the combination PID/SGID identifies both the
client/server protocol for which the servers of the SG are being
synchronized as well as the instance of that protocol. This implies
that multiple instances of the same protocol may be in operation at
the same time and have their servers synchronized independently of
each other. An example of types of information that must be
synchronized can be seen in NHRP[2] using IP where the information
includes the registered clients' IP to NBMA mappings in the SG LIS.
The simplest way to understand SCSP is to understand that the
algorithm used here is quite similar to that used in OSPF[3]. In
fact, if the reader wishes to understand more details of the
tradeoffs and reliability aspects of SCSP, they should refer to the
Hello, Database Synchronization, and Flooding Procedures in OSPF [3].
As described later, the protocol goes through three phases. The
first, very brief phase is the hello phase where two devices
determine that they can talk to each other. Following that is
database synchronization. The operation of SCSP assumes that up to
the point when new information is received, two entities have the
same data available. The database synchronization phase ensures
this.
Luciani, et. al. Standards Track