[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 2334

Internetworking Over NBMA                               James V. Luciani
INTERNET-DRAFT                                            (Bay Networks)
<draft-ietf-ion-scsp-01.txt>                          Grenville Armitage
                                                              (Bellcore)
                                                            Joel Halpern
                                                             (Newbridge)
                                                  Expires September 1997





              Server Cache Synchronization Protocol (SCSP)


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

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.





Luciani, et al.                                                 [Page 1]


INTERNET-DRAFT                    SCSP            Expires September 1997


1. Introduction

   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
   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 undo
   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.  SGs may exist in any topology as long as the resultant
   graph spans the set of servers that need to be synchronized.  The
   caches which are to be synchronized contain information on the state
   of the clients within the scope of interest of the SG.  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 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].




Luciani, et al.                                                 [Page 2]


INTERNET-DRAFT                    SCSP            Expires September 1997


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.

   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



Luciani, et al.                                                 [Page 3]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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.


                       +---------------+
                       |               |
              +-------@|     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.




Luciani, et al.                                                 [Page 4]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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.

   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 heard a Hello message, 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).  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



Luciani, et al.                                                 [Page 5]


INTERNET-DRAFT                    SCSP            Expires September 1997


   there are two HFSMs running on each side of the VC (one per
   PID/SGID).

   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 any properly
   formed SCSP messages other than Hello messages must be ignored (this
   is for the case where, for example, there is a point to multipoint
   connection involved).
































Luciani, et al.                                                 [Page 6]


INTERNET-DRAFT                    SCSP            Expires September 1997


                   +------------+
                   |            |
              +---@|    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



Luciani, et al.                                                 [Page 7]


INTERNET-DRAFT                    SCSP            Expires September 1997


   Advertisement Summary records (CSAS records).

   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.

   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) then the O bit is set to one and the initial set
        of CSAS records are included in the CA message.



Luciani, et al.                                                 [Page 8]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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:
     a) The timer counting down the CAReXmtInterval is stopped.
     b) The LS must process any CSAS records in the received CA message.
     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



Luciani, et al.                                                 [Page 9]


INTERNET-DRAFT                    SCSP            Expires September 1997


          (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 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.




Luciani, et al.                                                [Page 10]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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 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
   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



Luciani, et al.                                                [Page 11]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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
   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



Luciani, et al.                                                [Page 12]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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) an server receives a request from a client to add an entry to its
cache,
       2) an 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
   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



Luciani, et al.                                                [Page 13]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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.

     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
          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



Luciani, et al.                                                [Page 14]


INTERNET-DRAFT                    SCSP            Expires September 1997


          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
   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



Luciani, et al.                                                [Page 15]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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
   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.




Luciani, et al.                                                [Page 16]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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.


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



Luciani, et al.                                                [Page 17]


INTERNET-DRAFT                    SCSP            Expires September 1997


     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.

   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.

   RS - Remote Server (RS)



Luciani, et al.                                                [Page 18]


INTERNET-DRAFT                    SCSP            Expires September 1997


     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.


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,
   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, "unused" fields are set to zero on
   when transmitting a message and these fields are ignored on receipt
   of a message.

B.1 Fixed Part





Luciani, et al.                                                [Page 19]


INTERNET-DRAFT                    SCSP            Expires September 1997


    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 with
     the fixed header).

   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



Luciani, et al.                                                [Page 20]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Protocol ID           |        Server Group ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            unused             |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sender ID Len | Recvr ID Len  |       Number of Records       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Sender ID (variable length)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Receiver ID (variable length)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.  IANA will accept any and all requests for value
     assignment as long as the client/server protocol specific document
     exists.  Protocols with current documents have the 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.




Luciani, et al.                                                [Page 21]


INTERNET-DRAFT                    SCSP            Expires September 1997


   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.

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.
















Luciani, et al.                                                [Page 22]


INTERNET-DRAFT                    SCSP            Expires September 1997


    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
     proportional to the "diameter" of the SG being synchronized.

   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



Luciani, et al.                                                [Page 23]


INTERNET-DRAFT                    SCSP            Expires September 1997


     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.

   Cache Key
     This is a database lookup key that uniquely identifies a piece of
     data which the originator of a CSA Record wishes to synchronize
     with its peers for a given "Protocol ID/Server Group ID" pair.
     This key will generally be a small opaque byte string which SCSP
     will associate with a given piece of data in a cache.  Thus, for
     example, an originator might assign a particular 4 byte string to
     the binding of an IP address with that of an ATM address.
     Generally speaking, the originating server of a CSA record is
     responsible for generating a Cache Key for every element of data
     that the the given server originates and which the server wishes to
     synchronize with its peers in the SG.

   Originator ID
     This field contains an ID administratively assigned to the server
     which is the originator of CSA Records.


B.2.1 Cache Alignment (CA)

   The Cache Alignment (CA) message allows an LS to synchronize its
   entire cache with that of the cache of its DCSs within a server
   group. The CA message type code is 1. The CA message mandatory part
   format is as follows:











Luciani, et al.                                                [Page 24]


INTERNET-DRAFT                    SCSP            Expires September 1997


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     CA  Sequence Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mandatory Common Part                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          CSAS Record                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .......
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          CSAS Record                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CA Sequence Number
     A value which provides a unique identifier to aid in the sequencing
     of the cache alignment process.  A "larger" sequence number means a
     more recent CA message.  The slave server always copies the
     sequence number from the master server's previous CA message into
     its current CA message which it is sending and the the slave
     acknowledges the master's CA message.  Since the initial CA process
     is lock-step, if the slave does not receive the same sequence
     number which it previously received then the information in the
     slave's previous CA message is implicitly acknowledged. Note that
     there is a separate CA Sequence Number space associated with each
     CAFSM.

   Mandatory Common Part
     The mandatory common part is described in detail in Section
     B.2.0.1.  There are two fields in the mandatory common part whose
     codings are specific to a given message type.  These fields are the
     "Number of Records" field and the "Flags" field.

     Number of Records
       The Number of Records field of the mandatory common part for the
       CA message gives the number of CSAS Records appended to the CA
       message mandatory part.

     Flags
       The Flags field of the mandatory common part for the CA message
       has the following format:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |M|I|O|         unused          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Luciani, et al.                                                [Page 25]


INTERNET-DRAFT                    SCSP            Expires September 1997


       M
         This bit is part of the negotiation process for the cache
         alignment.  When this bit is set then the sender of the CA
         message is indicating that it wishes to lead the alignment
         process.  This bit is the "Master/Slave bit".

       I
         When set, this bit indicates that the sender of the CA message
         believes that it is in a state where it is negotiating for the
         status of master or slave.  This bit is the "Initialization
         bit".

       O
         This bit indicates that the sender of the CA message has more
         CSAS records to send.  This implies that the cache alignment
         process must continue.  This bit is the "mOre bit" despite its
         dubious name.

     All other fields of the mandatory common part are coded as
     described in Section B.2.0.1.

   CSAS record
     The CA message appends CSAS records to the end of its mandatory
     part.  These CSAS records are NOT embedded in CSA records.  See
     Section B.2.0.2 for details on CSAS records.


B.2.2 Cache State Update Request (CSU Request)

   The Cache State Update Request (CSU Request) message is used to
   update the state of cache entries in servers which are directly
   connected to the server sending the message.   A CSU Request message
   is sent from one server (the LS) to directly connected server (the
   DCS) when the LS observes changes in the state of one or more cache
   entries.  An LS observes such a change in state by either receiving a
   CSU request which causes an update to the LS's database or by
   observing a change of state of a cached entry originated by the LS.
   The change in state of a cache entry is noted in a CSU message by
   appending a "Cache State Advertisement" (CSA) record to the end of
   the mandatory part of the CSU Request as shown below.

   The CSU Request message type code is 2.  The CSU Request message
   mandatory part format is as follows:








Luciani, et al.                                                [Page 26]


INTERNET-DRAFT                    SCSP            Expires September 1997


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mandatory Common Part                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         CSA Record                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              .......
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         CSA Record                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Mandatory Common Part
     The mandatory common part is described in detail in Section
     B.2.0.1.  There are two fields in the mandatory common part whose
     codings are specific to a given message type.  These fields are the
     "Number of Records" field and the "Flags" field.

     Number of Records
       The Number of Records field of the mandatory common part for the
       CSU Request message gives the number of CSA Records appended to
       the CSU Request message mandatory part.

     Flags
       Currently, there are no flags defined for the Flags field of the
       mandatory common part for the CSU Request message.

     All other fields of the mandatory common part are coded as
     described in Section B.2.0.1.

   CSA Record
     See Section B.2.2.1.

B.2.2.1 Cache State Advertisement Record (CSA record)

   CSA records contain the information necessary to relate the current
   state of a cache entry in an SG to the servers being synchronized.
   CSA records contain a CSAS Record header and a client/server protocol
   specific part. The CSAS Record 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.  If the information contained in the
   CSA is more new than the cached entry of the receiving server then
   the cached entry is updated accordingly with the contents of the CSA
   Record.  The client/server protocol specific part of the CSA Record
   is documented separately for each such protocol.  Examples of the
   protocol specific parts for NHRP and ATMARP are shown in [8] and [9]



Luciani, et al.                                                [Page 27]


INTERNET-DRAFT                    SCSP            Expires September 1997


   respectively.

   The amount of information carried by a specific CSA record may exceed
   the size of a link layer PDU.  Hence, such CSA records MUST be
   fragmented across a number of CSU Request messages. The method by
   which this is done, is client/server protocol specific and is
   documented in the appropriate protocol specific document.

   The content of a CSA record is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          CSAS Record                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Client/Server Protocol Specific Part for cache entry ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CSAS Record
     See Section B.2.0.2 for rules and format for filling out a CSAS
     Record when it is "embedded" in a CSA Record.

   Client/Server Protocol Specific Part for cache entry
     This field contains the fields which are specific to the protocol
     specific portion of SCSP processing.  The particular set of fields
     are defined in separate documents for each protocol user of SCSP.
     The Protocol ID, which identifies which protocol is using SCSP in
     the given packet, is located in the mandatory part of the message.


B.2.3 Cache State Update Reply (CSU Reply)

   The Cache State Update Reply (CSU Reply) message is sent from a DCS
   to an LS to acknowledge one or more CSA records which were received
   in a CSU Request.  Reception of a CSA record in a CSU Request is
   acknowledged by including a CSAS record in the CSU Reply which
   corresponds to the CSA record being acknowledged.  The CSU Reply
   message is the same in format as the CSU Request message except for
   the following: the type code is 3, only CSAS Records (rather than CSA
   records) are returned, and only those CSAS Records for which CSA
   Records are being acknowledged are returned.  This implies that a
   given LS sending a CSU Request may not receive an acknowledgment in a
   single CSU Reply for all the CSA Records included in the CSU Request.








Luciani, et al.                                                [Page 28]


INTERNET-DRAFT                    SCSP            Expires September 1997


B.2.4 Cache State Update Solicit Message (CSUS message)
   This message allows one server (LS) to solicit the entirety of CSA
   record data stored in the cache of a directly connected server (DCS).
   The DCS responds with CSU Request messages containing the appropriate
   CSA records.  The CSUS message type code is 4.  The CSUS message
   format is the same as that of the CSU Reply message.  CSUS messages
   solicit CSU Requests from only one server (the one identified by the
   Receiver ID in the Mandatory Part of the message).


B.2.5 Hello:

   The Hello message is used to check connectivity between the sending
   server (the LS) and one of its directly connected neighbor servers
   (the DCSs).  The Hello message type code is 5.  The Hello message
   mandatory part format is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |          DeadFactor           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            unused             |          Family ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mandatory Common Part                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Additional Receiver ID Record                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               .........
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Additional Receiver ID Record                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   HelloInterval
     The hello interval advertises the time between sending of
     consecutive Hello Messages.  If the LS does not receive a Hello
     message from the DCS (which contains the LSID as a Receiver ID)
     within the HelloInterval advertised by the DCS then the DCS's Hello
     is considered to be late.  Also, the LS MUST send its own Hello
     message to a DCS within the HelloInterval which it advertised to
     the DCS in the LS's previous Hello message to that DCS (otherwise
     the DCS would consider the LS's Hello to be late).

   DeadFactor
     This is a multiplier to the HelloInterval. If an LS does not
     receive a Hello message which contains the LS's LSID as a Receiver
     ID within the interval HelloInterval*DeadFactor from a given DCS,
     which advertised the HelloInterval and DeadFactor in a previous



Luciani, et al.                                                [Page 29]


INTERNET-DRAFT                    SCSP            Expires September 1997


     Hello message, then the LS MUST consider the DCS to be stalled; at
     this point, one of two things MUST happen: 1) if the LS has
     received any Hello messages from the DCS during this time then the
     LS transitions the corresponding HFSM to the Unidirectional State;
     otherwise, 2) the LS transitions the corresponding HFSM to the
     Waiting State.

   Family ID
     This is an opaque bit string which is used to refer to an aggregate
     of Protocol ID/SGID pairs.  Only a single HFSM is run for all
     Protocol ID/SGID pairs assigned to a Family ID.  Thus, there is a
     one to many mapping between the single HFSM and the CAFSMs
     corresponding to each of the Protocol ID/SGID pairs.  This might
     have the net effect of substantially reducing HFSM maintenance
     traffic.  See the protocol specific SCSP documents for further
     details.

   Mandatory Common Part
     The mandatory common part is described in detail in Section
     B.2.0.1.  There are two fields in the mandatory common part whose
     codings are specific to a given message type.  These fields are the
     "Number of Records" field and the "Flags" field.

     Number of Records
       The Number of Records field of the mandatory common part for the
       Hello message contains the number of "Additional Receiver ID"
       records which are included in the Hello.  Additional Receiver ID
       records contain a length field and a Receiver ID field.  Note
       that the count in "Number of Records" does NOT include the
       Receiver ID which is included in the Mandatory Common Part.

     Flags
       Currently, there are no flags defined for the Flags field of the
       mandatory common part for the Hello message.

     All other fields of the mandatory common part are coded as
     described in Section B.2.0.1.

   Additional Receiver ID Record
     This record contains a length field followed by a Receiver ID.
     Since it is conceivable that the length of a given Receiver ID may
     vary even within an SG, each additional Receiver ID heard (beyond
     the first one) will have both its length in bytes and value encoded
     in an "Additional Receiver ID Record".  Receiver IDs are IDs of a
     DCS from which the LS has heard a recent Hello (i.e., within
     DeadFactor*HelloInterval as advertised by the DCS in a previous
     Hello message).




Luciani, et al.                                                [Page 30]


INTERNET-DRAFT                    SCSP            Expires September 1997


     The format for this record is as follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Rec ID Len   |                 Receiver ID                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   If the LS has not heard from any DCS then the LS sets the Hello
   message fields as follows: Recvr ID Len is set to zero and no storage
   is allocated for the Receiver ID in the Common Mandatory Part,
   "Number of Records" is set to zero, and no storage is allocated for
   "Additional Receiver ID Records".

   If the LS has heard from exactly one DCS then the LS sets the Hello
   message fields as follows: the Receiver ID of the DCS which was heard
   and the length of that Receiver ID are encoded in the Common
   Mandatory Part, "Number of Records" is set to zero, and no storage is
   allocated for "Additional Receiver ID Records".

   If the LS has heard from two or more DCSs then the LS sets the Hello
   message fields as follows: the Receiver ID of the first DCS which was
   heard and the length of that Receiver ID are encoded in the Common
   Mandatory Part, "Number of Records" is set to the number of
   "Additional" DCSs heard, and for each additional DCS an "Additional
   Receiver ID Record" is formed and appended to the end of the Hello
   message.


B.3  Extensions Part

   The Extensions Part, if present, carries one or more extensions in
   {Type, Length, Value} triplets.

   Extensions have the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
     The extension type code (see below).




Luciani, et al.                                                [Page 31]


INTERNET-DRAFT                    SCSP            Expires September 1997


   Length
     The length in octets of the value (not including the Type and
     Length fields;  a null extension will have only an extension header
     and a length of zero).

   When extensions exist, the extensions part is terminated by the End
   of Extensions extension, having Type = 0 and Length = 0.

   Extensions may occur in any order but any particular extension type
   may occur only once in an SCSP packet.  An LS MUST NOT change the
   order of extensions.


B.3.0  The End Of Extensions

    Type = 0
    Length = 0

   When extensions exist, the extensions part is terminated by the End
   Of Extensions extension.


B.3.1  SCSP Authentication Extension

    Type = 1
    Length = variable

   The SCSP Authentication Extension is carried in SCSP packets to
   convey authentication information between an LS and a DCS in the same
   SG.

   Authentication is done pairwise on an LS to DCS basis;  i.e., the
   authentication extension is generated at each LS. If a received
   packet fails the authentication test then an "abnormal event" has
   occurred.  Any "abnormal event" causes the HFSM associated with the
   server from which the packet was received to transition to the
   Waiting State.

   The presence or absence of the Authentication Extension is a local
   matter.











Luciani, et al.                                                [Page 32]


INTERNET-DRAFT                    SCSP            Expires September 1997


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Type                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Authentication Type field identifies the authentication method in
   use.  Currently assigned values are:

      1 - Cleartext Password
      2 - Keyed MD5

   All other values are reserved.

   The Authentication Data field contains the type-specific
   authentication information.

   In the case of Cleartext Password Authentication, the Authentication
   Data consists of a variable length password.

   In the case of Keyed MD5 Authentication, the Authentication Data
   contains the 16 byte MD5 digest of the entire SCSP packet, including
   the encapsulated protocol's header, with the authentication key
   appended to the end of the packet.  The authentication key is not
   transmitted with the packet.  The MD5 digest covers only the fixed
   part and mandatory part.


B.3.2  SCSP Vendor-Private Extension

    Type = 2
    Length = variable

   The SCSP Vendor-Private Extension is carried in SCSP packets to
   convey vendor-private information between an LS and a DCS in the same
   SG and is thus of limited use.  If a finer granularity (e.g., CSA
   record level) is desired then then given client/server protocol
   specific SCSP document MUST define such a mechanism.  Obviously,
   however, such a protocol specific mechanism might look exactly like
   this extension.  The Vendor Private Extension MAY NOT appear more
   than once in an SCSP packet for a given Vendor ID value.






Luciani, et al.                                                [Page 33]


INTERNET-DRAFT                    SCSP            Expires September 1997


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Vendor ID                    |  Data....     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor ID
     802 Vendor ID as assigned by the IEEE [10].

   Data
     The remaining octets after the Vendor ID in the payload are
     vendor-dependent data.

   If the receiver does not handle this extension, or does not match the
   Vendor ID in the extension then the extension may be completely
   ignored by the receiver.



References

[1] "Classical IP and ARP over ATM", Laubach, RFC 1577.

[2] "NBMA Next Hop Resolution Protocol (NHRP)", Luciani, Katz, Piscitello,
    Cole, draft-ietf-rolc-nhrp-11.txt.

[3] "OSPF Version 2", Moy, RFC1583.

[4] "P-NNI V1", Dykeman, Goguen, 1996.

[5] "Support for Multicast over UNI 3.0/3.1 based ATM Networks.",
    Armitage, RFC2022.

[6] LAN Emulation over ATM Version 2 - LNNI specification, Keene,
    btd-lane-lnni-02.08.

[7] Assigned Numbers, Reynolds, Postel, RFC 1700.

[8] "A Distributed NHRP Service Using SCSP", Luciani,
    draft-ietf-ion-scsp-nhrp-00.txt.

[9] "A Distributed ATMARP Service Using SCSP", Luciani,
    draft-ietf-ion-scsp-atmarp-00.txt.

[10] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700.






Luciani, et al.                                                [Page 34]


INTERNET-DRAFT                    SCSP            Expires September 1997


Acknowledgments

   This I-D is a distillation of issues raised during private
   discussions, on the IP-ATM mailing list, and during the Dallas IETF
   (12/95). Thanks to all who have contributed but particular thanks to
   following people (in no particular order):  Barbara Fox of Harris and
   Jeffries; Raj Nair, and Matthew Doar of Ascom Nexion; Andy Malis of
   Cascade; Andre Fredette of Bay Networks; James Watt of Newbridge; and
   Carl Marcinik of Fore.

Author's Address

   James V. Luciani
   Bay Networks, Inc.
   3 Federal Street, BL3-04
   Billerica, MA  01821
   phone: +1-508-916-4734
   email: luciani@baynetworks.com

   Grenville Armitage
   Bellcore, 445 South Street
   Morristown, NJ, 07960
   Email: gja@thumper.bellcore.com
   Ph. +1 201 829 2635

   Joel M. Halpern
   Newbridge Networks Corp.
   593 Herndon Parkway
   Herndon, VA 22070-5241
   Phone: +1-703-708-5954
   Email: jhalpern@Newbridge.COM




















Luciani, et al.                                                [Page 35]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/