rfc2334.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,392 行 · 第 1/5 页

Network Working Group                                         J. Luciani
Request for Comments: 2334                                  Bay Networks
Category: Standards Track                                    G. Armitage
                                                                Bellcore
                                                              J. Halpern
                                                               Newbridge
                                                            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.

Abstract

   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

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   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
   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                     [Page 2]

RFC 2334                          SCSP                        April 1998


   In database synchronization, the two neighbors exchange summary
   information about each entry in their database.  Summaries are used
   since the database itself is potentially quite large.  Based on these
   summaries, the neighbors can determine if there is information that
   each needs from the other.  If so, that is requested and provided.
   Therefore, at the end of this phase of operation, the two neighbors
   have the same data in their databases.

   After that, the entities enter and remain in flooding state.  In
   flooding state, any new information that is learned is sent to all
   neighbors, except the one (if any) that the information was learned
   from.  This causes all new information in the system to propagate to
   all nodes, thus restoring the state that everyone knows the same
   thing.  Flooding is done reliably on each link, so no pattern of low
   rate packet loss will cause a disruption.  (Obviously, a sufficiently
   high rate of packet loss will cause the entire neighbor relationship
   to come down, but if the link does not work, then that is what one
   wants.)

   Because the database synchronization procedure is run whenever a link
   comes up, the system robustly ensures that all participating nodes
   have all available information.  It properly recovers from
   partitions, and copes with other failures.

   The SCSP specification is not useful as a stand alone protocol.  It
   must be coupled with the use of an SCSP Protocol Specific
   specification which defines how a given protocol would make use of
   the synchronization primitives supplied by SCSP.  Such specification
   will be done in separate documents; e.g., [8] [9].

2. Overview

   SCSP places no topological requirements upon the SG.  Obviously,
   however, the resultant graph must span the set of servers to be
   synchronized.  SCSP borrows its cache distribution mechanism from the
   link state protocols [3,4].  However, unlike those technologies,
   there is no mandatory Shortest Path First (SPF) calculation, and SCSP
   imposes no additional memory requirements above and beyond that which
   is required to save the cached information which would exist
   regardless of the synchronization technology.











Luciani, et. al.            Standards Track                     [Page 3]

RFC 2334                          SCSP                        April 1998


   In order to give a frame of reference for the following discussion,
   the terms Local Server (LS), Directly Connected Server (DCS), and
   Remote Server (RS) are introduced.  The LS is the server under
   scrutiny; i.e., all statements are made from the perspective of the
   LS when discussing the SCSP protocol. The DCS is a server which is
   directly connected to the LS;  e.g., there exists a VC between the LS
   and DCS.  Thus, every server is a DCS from the point of view of every
   other server which connects to it directly, and every server is an LS
   which has zero or more DCSs directly connected to it. From the
   perspective of an LS, an RS is a server, separate from the LS, which
   is not directly connected to the LS (i.e., an RS is always two or
   more hops away from an LS whereas a DCS is always one hop away from
   an LS).

   SCSP contains three sub protocols: the "Hello" protocol, the "Cache
   Alignment" protocol, and the "Cache State Update" protocol.  The
   "Hello" protocol is used to ascertain whether a DCS is operational
   and whether the connection between the LS and DCS is bidirectional,
   unidirectional, or non-functional.  The "Cache Alignment" (CA)
   protocol allows an LS to synchronize its entire cache with that of
   the cache of its DCSs. The "Cache State Update" (CSU) protocol is
   used to update the state of cache entries in servers for a given SG.
   Sections 2.1, 2.2, and 2.3 contain a more in-depth explanation of the
   Hello, CA, and CSU protocols and the messages they use.

   SCSP based synchronization is performed on a per protocol instance
   basis.  That is, a separate instance of SCSP is run for each instance
   of the given protocol running in a given box.  The protocol is
   identified in SCSP via a Protocol ID and the instance of the protocol
   is identified by a Server Group ID (SGID).  Thus the PID/SGID pair
   uniquely identify an instance of SCSP.  In general, this is not an
   issue since it is seldom the case that many instances of a given
   protocol (which is distributed and needs cache synchronization) are
   running within the same physical box.  However, when this is the
   case, there is a mechanism called the Family ID (described briefly in
   the Hello Protocol) which enables a substantial reduction in
   maintenance traffic at little real cost in terms of control.  The use
   of the Family ID mechanism, when appropriate for a given protocol
   which is using SCSP, will be fully defined in the given SCSP protocol
   specific specification.











Luciani, et. al.            Standards Track                     [Page 4]

RFC 2334                          SCSP                        April 1998


                       +---------------+
                       |               |
              +------->|     DOWN      |<-------+
              |        |               |        |
              |        +---------------+        |
              |            |       ^            |
              |            |       |            |
              |            |       |            |
              |            |       |            |
              |            @       |            |
              |        +---------------+        |
              |        |               |        |
              |        |    WAITING    |        |
              |     +--|               |--+     |
              |     |  +---------------+  |     |
              |     |    ^           ^    |     |
              |     |    |           |    |     |
              |     @    |           |    @     |
            +---------------+     +---------------+
            | BIDIRECTIONAL |---->| UNIDIRECTIONAL|
            |               |     |               |
            |  CONNECTION   |<----|  CONNECTION   |
            +---------------+     +---------------+


          Figure 1: Hello Finite State Machine (HFSM)


2.1  Hello Protocol

   "Hello" messages are used to ascertain whether a DCS is operational
   and whether the connections between the LS and DCS are bidirectional,
   unidirectional, or non-functional. In order to do this, every LS MUST
   periodically send a Hello message to its DCSs.

   An LS must be configured with a list of NBMA addresses which
   represent the addresses of peer servers in a SG to which the LS
   wishes to have a direct connection for the purpose of running SCSP;
   that is, these addresses are the addresses of would-be DCSs.  The
   mechanism for the configuration of an LS with these NBMA address is
   beyond the scope of this document; although one possible mechanism
   would be an autoconfiguration server.

   An LS has a Hello Finite State Machine (HFSM) associated with each of
   its DCSs (see Figure 1) for a given SG, and the HFSM monitors the
   state of the connectivity between the servers.