rfc2334.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

          CSA Sequence Number in the CSAS Record of the the CSU Reply
          then the CSAS Record in the CSU Reply is ignored.
       b) If the CSA Record queued to the DCS retransmit queue has a
          CSA Sequence Number which is less than the
          CSA Sequence Number in the CSAS Record of the the CSU Reply
          then CSA Record which is queued to the DCS retransmit queue is
          dequeued and the CSA Record is disassociated with its timer.
          Further, a CSUS Message is sent to that DCS which sent the
          more up-to-date CSAS Record.  All normal CSUS processing
          occurs as if the CSUS were sent as part of the CA protocol.

   When an LS receives a CSU Request message which contains a CSA Record
   which contains a CSA Sequence Number which is smaller than the CSA
   Sequence number of the cached CSA then the LS MUST acknowledge the
   CSA record in the CSU Request but it MUST do so by sending a CSU
   Reply message containing the CSAS Record portion of the CSA Record
   stored in the cache and not the CSAS Record portion of the CSA Record
   contained in the CSU Request.

   An LS responds to CSUS messages from its DCSs by sending CSU Request
   messages containing the appropriate CSA records to the DCS.  If an LS
   receives a CSUS message containing a CSAS record for an entry which
   is no longer in its database (e.g., the entry timed out and was
   discarded after the Cache Alignment exchange completed but before the
   entry was requested through a CSUS message), then the LS will respond
   by copying the CSAS Record from the CSUS message into a CSU Request
   message and the LS will set the N bit signifying that this record is
   a NULL record since the cache entry no longer exists in the LS's
   cache.  Note that in this case, the "CSA Record" included in the CSU
   Request to signify the NULL cache entry is literally only a CSAS
   Record since no client/server protocol specific information exists
   for the cache entry.

   If an LS receives a CSA Record in a CSU Request from a DCS for which
   the LS has an identical CSA record posted to the corresponding DCS's
   DCS retransmit queue then the CSA Record on the DCS retransmit queue
   is considered to be implicitly acknowledged.  Thus, the CSA Record is
   dequeued from the DCS retransmit queue and is disassociated with its
   timer.  The CSA Record sent by the DCS MUST still be acknowledged by
   the LS in a CSU Reply, however.  This is useful in the case of point





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


   to multipoint connections where the rule that "when an LS receives a
   CSA record from a DCS, that LS floods the CSA Record to every DCS
   except the DCS from which it was received" might be broken.

   If an LS receives a CSU with a Receiver ID which is not equal to the
   LSID and is not set to all 0xFFs then the CSU must be discarded and
   ignored.  This is necessary since the LS may be a leaf of a point to
   multipoint connection with other servers in the LS's SG.

   An LS MAY send a CSU Request to the all 0xFFs Receiver ID when the LS
   is a root of a point to multipoint connection with a set of its DCSs.
   If an LS receives a CSU Request with the all 0xFFs Receiver ID then
   it MUST use the Sender ID in the CSU Request as the Receiver ID of
   the CSU Reply (i.e., it MUST unicast its response to the sender of
   the request) when responding.  If the LS wishes to send a CSU Request
   to the all 0xFFs Receiver ID then it MUST create a time-out and
   retransmit timer for each of the DCSs which are leaves of the point
   to multipoint connection prior to sending the CSU Request.  If in
   this case, the time-out and retransmit timer expires for a given DCS
   prior to acknowledgment of a given CSA Record then the LS MUST use
   the specific DCSID as the Receiver ID rather than the all 0xFFs
   Receiver ID.  Similarly, if it is necessary to re-send a CSA Record
   then the LS MUST specify the specific DCSID as the Receiver ID rather
   than the all 0xFFs Receiver ID.

   Note that if a set of servers are in a full mesh of point to
   multipoint connections, and one server of that mesh sends a CSU
   Request into that full mesh, and the sending server sends the CSA
   Records in the CSU Request to the all 0xFFs Receiver ID then it would
   not be necessary for every other server in the mesh to source their
   own CSU Request containing those CSA Records into the mesh in order
   to properly flood the CSA Records. This is because every server in
   the mesh would have heard the CSU Request and would have processed
   the included CSA Records as appropriate.  Thus, a server in a full
   mesh could consider the mesh to be a single logical port and so the
   rule that "when an LS receives a CSA record from a DCS, that LS
   floods the CSA Record to every DCS except the DCS from which it was
   received" is not broken.  A receiving server in the full mesh would
   still need to acknowledge the CSA records with CSU Reply messages
   which contain the LSID of the replying server as the Sender ID and
   the ID of the server which sent the CSU Request as the Receiver ID
   field.  In the time out and retransmit case, the Receiver ID of the
   CSU Request would be set to the specific DCSID which did not
   acknowledge the CSA Record (as opposed to the all 0xFFs Receiver ID).
   Since a full mesh emulates a broadcast media for the servers attached
   to the full mesh, use of SCSP on a broadcast medium might use this
   technique as well.  Further discussion of this use of a full mesh or
   use of a broadcast media is left to the client/server protocol



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


   specific documents.

2.4 The meaning of "More Up To Date"/"Newness"

   During the cache alignment process and during normal CSU processing,
   a CSAS Record is compared against the contents of an LS's cache entry
   to decide whether the information contained in the record is more "up
   to date" than the corresponding cache entry of the LS.

   There are three pieces of information which are used in determining
   whether a record contains information which is more "up to date" than
   the information contained in the cache entry of an LS which is
   processing the record: 1) the Cache Key, 2) the Originator which is
   described by an Originator ID (OID), and 3) the CSA Sequence number.
   See Section B.2.0.2 for more information on these fields.

   Given these three pieces of information, a CSAS record (be it part of
   a CSA Record or be it stand-alone) is considered to be more "up to
   date" than the information contained in the cache of an LS if all of
   the following are true:

     1) The Cache Key in the CSAS Record matches the stored Cache Key
        in the LS's cache entry,
     2) The OID in the CSAS Record matches the stored OID
        in the LS's cache entry,
     3) The CSA Sequence Number in the CSAS Record is greater than
        CSA Sequence Number in the LS's cache entry.

Discussion and Conclusions

   While the above text is couched in terms of synchronizing the
   knowledge of the state of a client within the cache of servers
   contained in a SG, this solution generalizes easily to any number of
   database synchronization problems (e.g., LECS synchronization).

   SCSP defines a generic flooding protocol.  There are a number of
   related issues relative to cache maintenance and topology maintenance
   which are more appropriately defined in the client/server protocol
   specific documents; for example, it might be desirable to define a
   generic cache entry time-out mechanism for a given protocol or to
   advertise adjacency information between servers so that one could
   obtain a topo-map of the servers in a SG.  When mechanisms like these
   are desirable, they will be defined in the client/server protocol
   specific documents.







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


Appendix A: Terminology and Definitions

   CA Message - Cache Alignment Message
     These messages allow an LS to synchronize its entire cache with
     that of the cache of one of its DCSs.

   CAFSM - Cache Alignment Finite State Machine
     The CAFSM monitors the state of the cache alignment between an LS
     and a particular DCS.  There exists one CAFSM per DCS as seen from
     an LS.

   CSA Record - Cache State Advertisement Record
     A CSA is a record within a CSU message which identifies an update
     to the status of a "particular" cache entry.

   CSAS Record - Cache State Advertisement Summary Record
     A CSAS contains a summary of the information in a CSA.  A server
     will send CSAS records describing its cache entries to another
     server during the cache alignment process.  CSAS records are also
     included in a CSUS messages when an LS wants to request the entire
     CSA from the DCS.  The LS is requesting the CSA from the DCS
     because the LS believes that the DCS has a more recent view of the
     state of the cache entry in question.

   CSU Message - Cache State Update message
     This is a message sent from an LS to its DCSs when the LS becomes
     aware of a change in state of a cache entry.

   CSUS Message - Cache State Update Solicit Message
     This message is sent by an LS to its DCS after the LS and DCS have
     exchanged CA messages.   The CSUS message contains one or more CSAS
     records which represent solicitations for entire CSA records (as
     opposed to just the summary information held in the CSAS).

   DCS - Directly Connected Server
     The DCS is a server which is directly connected to the LS; e.g.,
     there exists a VC between the LS and DCS. This term, along with the
     terms LS and RS, is used to give a frame of reference when talking
     about servers and their synchronization.  Unless explicitly stated
     to the contrary, there is no implied difference in functionality
     between a DCS, LS, and RS.

   HFSM - Hello Finite State Machine
     An LS has a HFSM associated with each of its DCSs.  The HFSM
     monitors the state of the connectivity between the LS and a
     particular DCS.





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


   LS - Local Server
     The LS is the server under scrutiny; i.e., all statements are made
     from the perspective of the LS.  This term, along with the terms
     DCS and RS, is used to give a frame of reference when talking about
     servers and their synchronization.  Unless explicitly stated to the
     contrary, there is no implied difference in functionality between a
     DCS, LS, and RS.

   LSID - Local Server ID
     The LSID is a unique token that identifies an LS.  This value might
     be taken from the protocol address of the LS.

   PID - Protocol ID
     This field contains an identifier which identifies the
     client/server protocol which is making use of SCSP for the given
     message.  The assignment of Protocol IDs for this field is given
     over to IANA as described in Section C.

   RS - Remote Server (RS)
     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).  Unless otherwise stated an RS refers to a
     server in the SG.  This term, along with the terms LS and DCS, is
     used to give a frame of reference when talking about servers and
     their synchronization.  Unless explicitly stated to the contrary,
     there is no implied difference in functionality between a DCS, LS,
     and RS.

   SG - Server Group
     The SCSP synchronizes caches (or a portion of the caches) of a set
     of server entities which are bound to a SG through some means
     (e.g., all servers belonging to a Logical IP Subnet (LIS)[1]).
     Thus an SG is just a grouping of servers around some commonality.

   SGID - Server Group ID
     This ID is a 16 bit identification field that uniquely identifies
     the instance client/server protocol for which the servers of the SG
     are being synchronized.  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.










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


Appendix B:  SCSP Message Formats

   This section of the appendix includes the message formats for SCSP.
   SCSP protocols are LLC/SNAP encapsulated with an LLC=0xAA-AA-03 and
   OUI=0x00-00-5e and PID=0x00-05.

   SCSP has 3 parts to every packet: the fixed part, the mandatory part,
   and the extensions part.  The fixed part of the message exists in
   every packet and is shown below.  The mandatory part is specific to
   the particular message type (i.e., CA, CSU Request/Reply, Hello,