rfc2334.txt

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

   The HFSM starts in the "Down" State and transitions to the "Waiting"
   State after NBMA level connectivity has been established.  Once in
   the Waiting State, the LS starts sending Hello messages to the DCS.
   The Hello message includes: a Sender ID which is set to the LS's ID
   (LSID), zero or more Receiver IDs which identify the DCSs from which
   the LS has recently heard a Hello message (as described below), and a
   HelloInterval and DeadFactor which will be described below.   At this
   point, the DCS may or may not already be sending its own Hello
   messages to the LS.

   When the LS receives a Hello message from one of its DCSs, the LS
   checks to see if its LSID is in one of the Receiver ID fields of that
   message which it just received, and the LS saves the Sender ID from
   that Hello message. If the LSID is in one of the Receiver ID fields
   then the LS transitions the HFSM to the Bidirectional Connection
   state otherwise it transitions the HFSM into the Unidirectional
   Connection state.  The Sender ID which was saved is the DCS's ID
   (DCSID).  At some point before the next time that the LS sends its
   own Hello message to the DCS, the LS will check the saved DCSID
   against a list of Receiver IDs which the LS uses when sending the
   LS's own Hello messages.  If the DCSID is not found in the list of
   Receiver IDs then it is added to that list before the LS sends its
   Hello message.

   Hello messages also contain a HelloInterval and a DeadFactor.  The
   Hello interval advertises the time (in seconds) between sending of
   consecutive Hello messages by the server which is sending the
   "current" Hello message.  That is, if the time between reception of
   Hello messages from a DCS exceeds the HelloInterval advertised by
   that DCS then the next Hello message is to be considered late by the
   LS.  If the LS does not receive a Hello message, which contains the
   LS's LSID in one of the Receiver ID fields, within the interval
   HelloInterval*DeadFactor seconds (where DeadFactor was advertised by
   the DCS in a previous Hello message) then the LS MUST consider the
   DCS to be stalled.  At which point one of two things will happen: 1)
   if any Hello messages have been received during the last
   HelloInterval*DeadFactor seconds then the LS should transition the
   HFSM for that DCS to the Unidirectional Connection State; otherwise,
   the LS should transition the HFSM for that DCS to the Waiting State
   and remove the DCSID from the Receiver ID list.

   Note that the Hello Protocol is on a per PID/SGID basis. Thus, for
   example, if there are two servers (one in SG A and the other in SG B)
   associated with an NBMA address X and another two servers (also one
   in SG A and the other in SG B) associated with NBMA address Y and
   there is a suitable point-to-point VC between the NBMA addresses then
   there are two HFSMs running on each side of the VC (one per
   PID/SGID).



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


   Hello messages contain a list of Receiver IDs instead of a single
   Receiver ID in order to make use of point to multipoint connections.
   While there is an HFSM per DCS, an LS MUST send only a single Hello
   message to its DCSs attached as leaves of a point to multipoint
   connection.  The LS does this by including DCSIDs in the list of
   Receiver IDs when the LS's sends its next Hello message.  Only the
   DCSIDs from non-stalled DCSs from which the LS has heard a Hello
   message are included.

   Any abnormal event, such as receiving a malformed SCSP message,
   causes the HFSM to transition to the Waiting State; however, a loss
   of NBMA connectivity causes the HFSM to transition to the Down State.
   Until the HFSM is in the Bidirectional Connection State, if any
   properly formed SCSP messages other than Hello messages are received
   then those messages MUST be ignored (this is for the case where, for
   example, there is a point to multipoint connection involved).



































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


                   +------------+
                   |            |
              +--->|    DOWN    |
              |    |            |
              |    +------------+
              |          |
              ^          |
              |          @
              |    +------------+
              |    |Master/Slave|
              |-<--|            |<---+
              |    |Negotiation |    |
              |    +------------+    |
              |          |           |
              ^          |           ^
              |          @           |
              |    +------------+    |
              |    |   Cache    |    |
              |-<--|            |-->-|
              |    | Summarize  |    |
              |    +------------+    |
              |          |           |
              ^          |           ^
              |          @           |
              |    +------------+    |
              |    |   Update   |    |
              |-<--|            |-->-|
              |    |   Cache    |    |
              |    +------------+    |
              |          |           |
              ^          |           ^
              |          @           |
              |    +------------+    |
              |    |            |    |
              +-<--|  Aligned   |-->-+
                   |            |
                   +------------+

     Figure 2: Cache Alignment Finite State Machine


2.2 Cache Alignment Protocol

   "Cache Alignment" (CA) messages are used by an LS to synchronize its
   cache with that of the cache of each of its DCSs.  That is, CA
   messages allow a booting LS to synchronize with each of its DCSs.  A
   CA message contains a CA header followed by zero or more Cache State
   Advertisement Summary records (CSAS records).



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


   An LS has a Cache Alignment Finite State Machine (CAFSM) associated
   (see Figure 2) with each of its DCSs on a per PID/SGID basis, and the
   CAFSM monitors the state of the cache alignment between the servers.
   The CAFSM starts in the Down State.  The CAFSM is associated with an
   HFSM, and when that HFSM reaches the Bidirectional State, the CAFSM
   transitions to the Master/Slave Negotiation State.  The Master/Slave
   Negotiation State causes either the LS or DCS to take on the role of
   master over the cache alignment process.  In a sense, the master
   server sets the tempo for the cache alignment.

   When the LS's CAFSM reaches the Master/Slave Negotiation State, the
   LS will send a CA message to the DCS associated with the CAFSM.  The
   format of CA messages are described in Section B.2.1.  The first CA
   message which the LS sends includes no CSAS records and a CA header
   which contains the LSID in the Sender ID field, the DCSID in the
   Receiver ID field, a CA sequence number, and three bits.  These three
   bits are the M (Master/Slave) bit, the I (Initialization of master)
   bit, and the O (More) bit. In the first CA message sent by the LS to
   a particular DCS, the M, O, and I bits are set to one.  If the LS
   does not receive a CA message from the DCS in CAReXmtInterval seconds
   then it resends the CA message it just sent.  The LS continues to do
   this until the CAFSM transitions to the Cache Summarize State or
   until the HFSM transitions out of the Bidirectional State.  Any time
   the HFSM transitions out of the Bidirectional State, the CAFSM
   transitions to the Down State.

2.2.1 Master Slave Negotiation State

   When the LS receives a CA message from the DCS while in the
   Master/Slave Negotiation State, the role the LS plays in the exchange
   depends on packet processing as follows:

   1) If the CA from the DCS has the M, I, and O bits set to one and
      there are no CSAS records in the CA message and the Sender ID
      as specified in the DCS's CA message is larger than the LSID then

     a) The timer counting down the CAReXmtInterval is stopped.
     b) The CAFSM corresponding to that DCS transitions to the
        Cache Summarize    State and the LS takes on the role of slave.
     c) The LS adopts the CA sequence number it received in the CA
        message as its own CA sequence number.
     d) The LS sends a CA message to the DCS which is formated as
        follows: the M and I bits are set to zero, the Sender ID field
        is set to the LSID, the Receiver ID field is set to the DCSID,
        and the CA sequence number is set to the CA sequence number that
        appeared in the DCS's CA message.  If there are CSAS records to
        be sent (i.e., if the LS's cache is not empty), and if all of
        them will not fit into this CA message then the O bit is set to



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


        one and the initial set of CSAS records are included in the CA
        message; otherwise the O bit is set to zero and if any CSAS
        Records need to be sent then those records are included in the
        CA message.

   2) If the CA message from the DCS has the M and I bits off and the
      Sender ID as specified in the DCS's CA message is smaller than
      the LSID then

     a) The timer counting down the CAReXmtInterval is stopped.
     b) The CAFSM corresponding to that DCS transitions to the
        Cache Summarize State and the LS takes on the role of master.
     c) The LS must process the received CA message.
        An explanation of CA message processing is given below.
     d) The LS sends a CA message to the DCS which is formated as
        follows: the M bit is set to one, I bit is set to zero, the
        Sender ID field is set to the LSID, the Receiver ID field is set
        to the DCSID, and the LS's current CA sequence number is
        incremented by one and placed in the CA message.   If there are
        any CSAS records to be sent from the LS to the DCS (i.e., if the
        LS's cache is not empty) then the O bit is set to one and the
        initial set of CSAS records are included in the CA message that
        the LS is sending to the DCS.

   3) Otherwise, the packet must be ignored.

2.2.2 The Cache Summarize State

   At any given time, the master or slave have at most one outstanding
   CA message.  Once the LS's CAFSM has transitioned to the Cache
   Summarize State the sequence of exchanges of CA messages occurs as
   follows:

   1) If the LS receives a CA message with the M bit set incorrectly
      (e.g., the M bit is set in the CA of the DCS and the LS is master)
      or if the I bit is set then the CAFSM transitions back to the
      Master/Slave Negotiation State.

   2) If the LS is master and the LS receives a CA message with a
      CA sequence number which is one less than the LS's current
      CA sequence number then the message is a duplicate and the message
      MUST be discarded.

   3) If the LS is master 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 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:



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


     a) The timer counting down the CAReXmtInterval is stopped.
     b) The LS must process any CSAS records in the received CA message.