Server Cache Synchronization Protocol (SCSP)
RFC 2334

Document Type RFC - Proposed Standard (April 1998; Errata)
Authors Naganand Doraswamy  , Joel Halpern  , James Luciani  , Grenville Armitage 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2334 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         J. Luciani
Request for Comments: 2334                                  Bay Networks
Category: Standards Track                                    G. Armitage
                                                              J. Halpern
                                                            N. Doraswamy
                                                            Bay Networks
                                                              April 1998

              Server Cache Synchronization Protocol (SCSP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document describes the Server Cache Synchronization Protocol
   (SCSP) and is written in terms of SCSP's use within Non Broadcast
   Multiple Access (NBMA) networks; although, a somewhat straight
   forward usage is applicable to BMA networks.  SCSP attempts to solve
   the generalized cache synchronization/cache-replication problem for
   distributed protocol entities.  However, in this document, SCSP is
   couched in terms of the client/server paradigm in which distributed
   server entities, which are bound to a Server Group (SG) through some
   means, wish to synchronize the contents (or a portion thereof) of
   their caches which contain information about the state of clients
   being served.

1. Introduction

   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [10].

   It is perhaps an obvious goal for any protocol to not limit itself to
   a single point of failure such as having a single server in a
   client/server paradigm.  Even when there are redundant servers, there

Luciani, et. al.            Standards Track                     [Page 1]
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
Show full document text