rfc2334.txt

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

     c) Increment the LS's CA sequence number by one.
     d) The cache exchange continues as follows:

       1) If the LS has no more CSAS records to send and the received CA
          message has the O bit off then the CAFSM transitions to the
          Update Cache State.
       2) If the LS has no more CSAS records to send and the received CA
          message has the O bit on then the LS sends back a CA message
          (with new CA sequence number) which contains no CSAS records
          and with the O bit off.  Reset the timer counting down the
          CAReXmtInterval.
       3) If the LS has more CSAS records to send then the LS sends the
          next CA message with the LS's next set of CSAS records.  If LS
          is sending its last set of CSAS records then the O bit is set
          off otherwise the O bit is set on. Reset the timer counting
          down the CAReXmtInterval.

   4) If the LS is slave and the LS receives a CA message with a
      CA sequence number which is equal to the LS's current
      CA sequence number then the CA message is a duplicate and the
      LS MUST resend the CA message which it had just sent to the DCS.

   5) If the LS is slave and the LS receives a CA message with a
      CA sequence number which is one more than the LS's current
      CA sequence number then the message is valid and MUST be
      processed.  An explanation of "CA message processing" is given
      below.  As a result of having received the CA message from the
      DCS the following will occur:

     a) The LS must process any CSAS records in the received CA message.
     b) Set the LS's CA sequence number to the CA sequence number in the
        CA message.
     c) The cache exchange continues as follows:

       1) If the LS had just sent a CA message with the O bit off and
          the received CA message has the O bit off then the CAFSM
          transitions to the Update Cache State and the LS sends a CA
          message with no CSAS records and with the O bit off.
       2) If the LS still has CSAS records to send then the LS MUST send
          a CA message with CSAS records in it.

         a) If the message being sent from the LS to the DCS does not
            contain the last CSAS records that the LS needs to send
            then the CA message is sent with the O bit on.
         b) If the message being sent from the LS to the DCS does
            contain the last CSAS records that the LS needs to



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


            send and the CA message just received from the DCS had the
            O bit off then the CA message is sent with the O bit off,
            and the LS transitions the CAFSM to the Update Cache State.
         c) If the message being sent from the LS to the DCS does
            contain the last CSAS records that the LS needs to send
            and the CA message just received from the DCS had the O bit
            on then the CA message is sent with the O bit off and the
            alignment process continues.

   6) If the LS is slave and the LS receives a CA message with a
      CA sequence number that is neither equal to nor one more than
      the current LS's CA sequence number then an error has occurred
      and the CAFSM transitions to the Master/Slave Negotiation State.

   Note that if the LS was slave during the CA process then the LS upon
   transitioning the CAFSM to the Update Cache state MUST keep a copy of
   the last CA message it sent and the LS SHOULD set a timer equal to
   CAReXmtInterval. If either the timer expires or the LS receives a CSU
   Solicit (CSUS) message (CSUS messages are described in Section 2.2.3)
   from the DCS then the LS releases the copy of the CA message.  The
   reason for this is that if the DCS (which is master) loses the last
   CA message sent by the LS then the DCS will resend its previous CA
   message with the last CA Sequence number used.  If that were to occur
   the LS would need to resend its last sent CA message as well.

2.2.2.1 "CA message processing":

   The LS makes a list of those cache entries which are more "up to
   date" in the DCS than the LS's own cache.  This list is called the
   CSA Request List (CRL).  See Section 2.4 for a description of what it
   means for a CSA (Client State Advertisement) record or CSAS record to
   be more "up to date" than an LS's cache entry.

2.2.3 The Update Cache State

   If the CRL of the associated CAFSM of the LS is empty upon transition
   into the Update Cache State then the CAFSM immediately transitions
   into the Aligned State.

   If the CRL is not empty upon transition into the Update Cache State
   then the LS solicits the DCS to send the CSA records corresponding to
   the summaries (i.e., CSAS records) which the LS holds in its CRL. The
   solicited CSA records will contain the entirety of the cached
   information held in the DCS's cache for the given cache entry.  The
   LS solicits the relevant CSA records by forming CSU Solicit (CSUS)
   messages from the CRL. See Section B.2.4 for the description of the
   CSUS message format.  The LS then sends the CSUS messages to the DCS.
   The DCS responds to the CSUS message by sending to the LS one or more



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


   CSU Request messages containing the entirety of newer cached
   information identified in the CSUS message.  Upon receiving the CSU
   Request the LS will send one or more CSU Replies as described in
   Section 2.3.  Note that the LS may have at most one CSUS message
   outstanding at any given time.

   Just before the first CSUS message is sent from an LS to the DCS
   associated with the CAFSM, a timer is set to CSUSReXmtInterval
   seconds.  If all the CSA records corresponding to the CSAS records in
   the CSUS message have not been received by the time that the timer
   expires then a new CSUS message will be created which contains all
   the CSAS records for which no appropriate CSA record has been
   received plus additional CSAS records not covered in the previous
   CSUS message.  The new CSUS message is then sent to the DCS.  If, at
   some point before the timer expires, all CSA record updates have been
   received for all the CSAS records included in the previously sent
   CSUS message then the timer is stopped.  Once the timer is stopped,
   if there are additional CSAS records that were not covered in the
   previous CSUS message but were in the CRL then the timer is reset and
   a new CSUS message is created which contains only those CSAS records
   from the CRL which have not yet been sent to the DCS.  This process
   continues until all the CSA records corresponding CSAS records that
   were in the CRL have been received by the LS.  When the LS has a
   completely updated cache then the LS transitions CAFSM associated
   with the DCS to the Aligned State.

   If an LS receives a CSUS message or a CA message with a Receiver ID
   which is not the LS's LSID then the message must be discarded and
   ignored.  This is necessary since an LS may be a leaf of a point to
   multipoint connection with other servers in the SG.

2.2.4 The Aligned State

   While in the Aligned state, an LS will perform the Cache State Update
   Protocol as described in Section 2.3.

   Note that an LS may receive a CSUS message while in the Aligned State
   and, the LS MUST respond to the CSUS message with the appropriate CSU
   Request message in a similar fashion to the method previously
   described in Section 2.2.3.

2.3 Cache State Update Protocol

   "Cache State Update" (CSU) messages are used to dynamically update
   the state of cache entries in servers on a given PID/SGID basis. CSU
   messages contain zero or more "Cache State Advertisement" (CSA)
   records each of which contains its own snapshot of the state of a
   particular cache entry.  An LS may send/receive a CSU to/from a DCS



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


   only when the corresponding CAFSM is in either the Aligned State or
   the Update Cache State.

   There are two types of CSU messages: CSU Requests and CSU Replies.
   See Sections B.2.2 and B.2.3 respectively for message formats.  A CSU
   Request message is sent from an LS to one or more DCSs for one of two
   reasons: either the LS has received a CSUS message and MUST respond
   only to the DCS which originated the CSUS message, or the LS has
   become aware of a change of state of a cache entry.  An LS becomes
   aware of a change of state of a cache entry either through receiving
   a CSU Request from one of its DCSs or as a result of a change of
   state being observed in a cached entry originated by the LS.  In the
   former case, the LS will send a CSU Request to each of its DCSs
   except the DCS from which the LS became aware of the change in state.
   In the latter case, the LS will send a CSU Request to each of its
   DCSs.  The change in state of a particular cache entry is noted in a
   CSA record which is then appended to the end of the CSU Request
   message mandatory part. In this way, state changes are propagated
   throughout the SG.

   Examples of such changes in state are as follows:

       1) a server receives a request from a client to add an entry to
          its cache,
       2) a server receives a request from a client to remove an entry
          from its cache,
       3) a cache entry has timed out in the server's cache, has been
          refreshed in the server's cache, or has been administratively
          modified.

   When an LS receives a CSU Request from one of its DCSs, the LS
   acknowledges one or more CSA Records which were contained in the CSU
   Request by sending a CSU Reply.  The CSU Reply contains one or more
   CSAS records which correspond to those CSA records which are being
   acknowledged.  Thus, for example, if a CSA record is dropped (or
   delayed in processing) by the LS because there are insufficient
   resources to process it then a corresponding CSAS record is not
   included in the CSU Reply to the DCS.

   Note that an LS may send multiple CSU Request messages before
   receiving a CSU Reply acknowledging any of the CSA Records contained
   in the CSU Requests.  Note also that a CSU Reply may contain
   acknowledgments for CSA Records from multiple CSU Requests.  Thus,
   the terms "request" and "reply" may be a bit confusing.

   Note that a CSA Record contains a CSAS Record followed by
   client/server protocol specific information contained in a cache
   entry  (see Section B.2.0.2 for CSAS record format information and



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


   Section B.2.2.1 for CSA record format information).  When a CSA
   record is considered by the LS to represent cached information which
   is more "up to date" (see Section 2.4) than the cached information
   contained within the cache of the LS then two things happen:  1) the
   LS's cache is updated with the more up to date information, and 2)
   the LS sends a CSU Request containing the CSA Record to each of its
   DCSs except the one from which the CSA Record arrived.  In this way,
   state changes are propagated within the PID/SGID.  Of course, at some
   point, the LS will also acknowledge the reception of the CSA Record
   by sending the appropriate DCS a CSU Reply message containing the
   corresponding CSAS Record.

   When an LS sends a new CSU Request, the LS keeps track of the
   outstanding CSA records in that CSU Request and to which DCSs the LS
   sent the CSU Request.  For each DCS to which the CSU Request was
   sent, a timer set to CSUReXmtInterval seconds is started just prior
   to sending the CSU Request.  This timer is associated with the CSA
   Records contained in that CSU Request such that if that timer expires
   prior to having all CSA Records acknowledged from that DCS then (and
   only then) a CSU Request is re-sent by the LS to that DCS.  However,
   the re-sent CSU Request only contains those CSA Records which have
   not yet been acknowledged.  If all CSA Records associated with a
   timer becomes acknowledged then the timer is stopped. Note that the
   re-sent CSA Records follow the same time-out and retransmit rules as
   if they were new.  Retransmission will occur a configured number of
   times for a given CSA Record and if acknowledgment fails to occur
   then an "abnormal event" has occurred at which point the then the
   HFSM associated with the DCS is transitioned to the Waiting State.

   A CSA Record instance is said to be on a "DCS retransmit queue" when
   it is associated with the previously mentioned timer.  Only the most
   up-to-date CSA Record is permitted to be queued to a given DCS
   retransmit queue.  Thus, if a less up-to-date CSA Record is queued to
   the DCS retransmit queue when a newer CSA Record instance is about to
   be queued to that DCS retransmit queue then the older CSA Record
   instance is dequeued and disassociated with its timer immediately
   prior to enqueuing the newer instance of the CSA Record.

   When an LS receives a CSU Reply from one of its DCSs then the LS
   checks each CSAS record in the CSU Reply against the CSAS Record
   portion of the CSA Records which are queued to the DCS retransmit
   queue.

     1) If there exists an exact match between the CSAS record portion
        of the CSA record and a CSAS Record in the CSU Reply then
        that CSA Record is considered to be acknowledged and is thus
        dequeued from the DCS retransmit queue and is
        disassociated with its timer.



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


     2) If there exists a match between the CSAS record portion
        of the CSA record and a CSAS Record in the CSU Reply except
        for the CSA Sequence number then

       a) If the CSA Record queued to the DCS retransmit queue has a
          CSA Sequence Number which is greater than the