rfc2334.txt

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

   CSUS) and, it includes (among other packet elements) a Mandatory
   Common Part and zero or more records each of which contains
   information pertinent to the state of a particular cache entry
   (except in the case of a Hello message) whose information is being
   synchronized within a SG. The extensions part contains the set of
   extensions for the SCSP message.

   In the following message formats, the fields marked as "unused" MUST
   be set to zero upon transmission of such a message and ignored upon
   receipt of such a message.

B.1 Fixed Part

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |  Type Code    |        Packet Size            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |      Start Of Extensions      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version
     This is the version of the SCSP protocol being used.  The current
     version is 1.

   Type Code
     This is the code for the message type (e.g., Hello (5), CSU
     Request(2), CSU Reply(3), CSUS (4), CA (1)).

   Packet Size
     The total length of the SCSP packet, in octets (excluding link
     layer and/or other protocol encapsulation).

   Checksum
     The standard IP checksum over the entire SCSP packet starting at
     the fixed header.  If the packet is an odd number of bytes in
     length then this calculation is performed as if a byte set to 0x00
     is appended to the end of the packet.



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


   Start Of Extensions
     This field is coded as zero when no extensions are present in the
     message.  If extensions are present then this field will be coded
     with the offset from the top of the fixed header to the beginning
     of the first extension.

B.2.0 Mandatory Part

   The mandatory part of the SCSP packet contains the operation specific
   information for a given message type (e.g., SCSP Cache State Update
   Request/Reply, etc.), and it includes (among other packet elements) a
   Mandatory Common Part (described in Section B.2.0.1) and zero or more
   records each of which contains information pertinent to the state of
   a particular cache entry (except in the case of a Hello message)
   whose information is being synchronized within a SG.  These records
   may, depending on the message type, be either Cache State
   Advertisement Summary (CSAS) Records (described in Section B.2.0.2)
   or Cache State Advertisement (CSA) Records (described in Section
   B.2.2.1).  CSA Records contain a summary of a cache entry's
   information (i.e., a CSAS Record) plus some additional client/server
   protocol specific information.  The mandatory common part format and
   CSAS Record format is shown immediately below, prior to showing their
   use in SCSP messages, in order to prevent replication within the
   message descriptions.

B.2.0.1 Mandatory Common Part

   Sections B.2.1 through B.2.5 have a substantial overlap in format.
   This overlapping format is called the mandatory common part and its
   format is shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Protocol ID           |        Server Group ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            unused             |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sender ID Len | Recvr ID Len  |       Number of Records       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Sender ID (variable length)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Receiver ID (variable length)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







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


   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.  Protocols with current
     documents have the following defined values:

       1 - ATMARP
       2 - NHRP
       3 - MARS
       4 - DHCP
       5 - LNNI

   Server Group ID
     This ID is uniquely identifies the instance of a given
     client/server protocol for which servers are being synchronized.

   Flags
     The Flags field is message specific, and its use will be described
     in the specific message format sections below.

   Sender ID Len
     This field holds the length in octets of the Sender ID.

   Recvr ID Len
     This field holds the length in octets of the Receiver ID.

   Number of Records
     This field contains the number of additional records associated
     with the given message.  The exact format of these records is
     specific to the message and will be described for each message type
     in the sections below.

   Sender ID
     This is an identifier assigned to the server which is sending the
     given message.  One possible assignment might be the protocol
     address of the sending server.

   Receiver ID
     This is an identifier assigned to the server which is to receive
     the given message.  One possible assignment might be the protocol
     address of the server which is to receive the given message.









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


B.2.0.2 Cache State Advertisement Summary Record (CSAS record)

   CSAS records contain a summary of information contained in a cache
   entry of a given client/server database which is being synchronized
   through the use of SCSP.  The summary includes enough information for
   SCSP to look into the client/server database for the appropriate
   database cache entry and then compare the "newness" of the summary
   against the "newness" of the cached entry.

   Note that CSAS records do not contain a Server Group ID (SGID) nor do
   they contain a Protocol ID.  These IDs are necessary to identify
   which protocol and which instance of that protocol for which the
   summary is applicable.  These IDs are present in the mandatory common
   part of each message.

   Note also that the values of the Hop Count and Record Length fields
   of a CSAS Record are dependent on whether the CSAS record exists as a
   "stand-alone" record or whether the CSAS record is "embedded" in CSA
   Record.  This is further described below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Hop Count           |        Record Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cache Key Len |  Orig ID Len  |N|          unused             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       CSA Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Cache Key  ...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Originator ID   ...                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Hop Count
     This field represents the number of hops that the record may take
     before being dropped.  Thus, at each server that the record
     traverses, the Hop Count is decremented.  This field is set to 1
     when the CSAS record is a "stand-alone" record (i.e., it is not
     embedded within a CSA record) since summaries do not go beyond one
     hop during the cache alignment process.  If a CSAS record is
     "embedded" within a CSA record then the Hop Count is set to an
     administratively defined value which is almost certainly greater
     than or equal to the the cardinality of the SG minus one.  Note
     that an exception to the previous rule occurs when the CSA Record
     is carried within a CSU Request which was sent in response to a
     solicitation (i.e., in response to a CSAS Record which was sent in
     a CSUS message); in which case, the Hop Count SHOULD be set to 1.



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


   Record Length
     If the CSAS record is a "stand-alone" record then this value is
     12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this value
     is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/Server
     Protocol Specific Part for cache entry").  The size of the
     Client/Server Protocol Specific Part may be obtained from the
     client/server protocol specific document for the given Protocol ID.

   Cache Key Len
     Length of the Cache Key field in bytes.

   Orig ID Len.
     Length of the Originator ID field in bytes.

   N
     The "N" bit signifies that this CSAS Record is actually a Null
     record.  This bit is only used in a CSAS Record contained in a CSU
     Request/Reply which is sent in response to a CSUS message.  It is
     possible that an LS may receive a solicitation for a CSA record
     when the cache entry represented by the solicited CSA Record no
     longer exists in the LS's cache (see Section 2.3 for details).  In
     this case, the LS copies the CSAS Record directly from the CSUS
     message into the CSU Request, and the LS sets the N bit signifying
     that the cache entry does not exist any longer.  The DCS which
     solicited the CSA record which no longer exists will still respond
     with a CSU Reply.  This bit is usually set to zero.

   CSA Sequence Number
     This field contains a sequence number that identifies the "newness"
     of a CSA record instance being summarized.  A "larger" sequence
     number means a more recent advertisement.  Thus, if the state of
     part (or all) of a cache entry needs to be updated then the CSA
     record advertising the new state MUST contain a CSA Sequence Number
     which is larger than the one corresponding to the previous
     advertisement.  This number is assigned by the originator of the
     CSA record.  The CSA Sequence Number may be assigned by the
     originating server or by the client which caused its server to
     advertise its existence.

     The CSA Sequence Number is a signed 32 bit number.  Within the CSA
     Sequence Number space, the number -2^31 (0x80000000) is reserved.
     Thus, the usable portion of the CSA Sequence Number space for a
     given Cache Key is between the numbers -2^31+1 (0x80000001) and
     2^31-1 (0x7fffffff).  An LS uses -2^31+1 the first time it
     originates a CSA Record for a cache entry that it created.  Each
     time the cache entry is modified in some manner and when that
     modification needs to be synchronized with the other servers in the
     SG, the LS increments the CSA Sequence number associated with the



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


     given Cache Key and uses that new CSA Sequence Number when
     advertising the update.  If it is ever the case that a given CSA
     Sequence Number has reached 2^31-2 and the associated cache entry
     has been modified such that an update must be sent to the rest of
     the servers in the SG then the given cache entry MUST first be
     purged from the SG by the LS by sending a CSA Record which causes
     the cache entry to be removed from other servers and this CSA
     Record carries a CSA Sequence Number of 2^31-1.  The exact packet
     format and mechanism by which a cache entry is purged is defined in
     the appropriate protocol specific document.  After the purging CSA
     Record has been acknowledged by each DCS, an LS will then send a
     new CSA Record carrying