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

Versions: 00 01 02

Network Working Group                                           R. Droms
INTERNET DRAFT                                       Bucknell University

                                                                 R. Cole
                                                                AT&T MNS

                                                              March 1997
                                                     Expires August 1997




                   An Inter-server Protocol for DHCP
                  <draft-ietf-dhc-interserver-01.txt>



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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   The DHCP protocol is designed to allow for multiple DHCP servers, so
   that reliability of DHCP service can be improved through the use of
   redundant servers.  To provide redundant service, multiple DHCP
   servers must carry the same information about assigned IP addresses
   and parameters; i.e., the servers must be configured with the same
   bindings.  Because DHCP servers may dynamically assign new addresses
   or configuration parameters, or extend the lease on an existing
   address assignment, the bindings on some servers may become out of
   date.  The DHCP inter-server protocol provides an automatic mechanism
   for synchronization of the bindings stored on a set of cooperating
   DHCP servers.  The underlying capabilities of the DHCP inter-server



Droms, Cole                                                     [Page 1]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   protocol required for multiple server cache replications are based
   upon the Server Cache Synchronization Protocol (SCSP).

1.  Introduction

   DHCP servers manage the assignment of IP address and configuration
   parameters to IP hosts.  The DHCP protocol specification [1] refers
   to the collection of configuration information assigned to a client
   as a "binding".  The DHCP protocol is designed to allow for multiple
   DHCP servers, so that reliability of DHCP service can be improved
   through the use of redundant servers.  To provide redundant service,
   the distributed DHCP servers' databases must be configured with the
   same information about assigned IP addresses and parameters; i.e.,
   client bindings must be replicated in multiple server databases.
   Because DHCP servers may dynamically assign new addresses or
   configuration parameters, or extend the lease on an existing address
   assignment, the bindings on some servers may become out of date.  The
   DHCP inter-server protocol provides an automatic mechanism for
   synchronization of the bindings stored on a set of cooperating DHCP
   servers.

   Much of the underlying capabilities provided by the DHCP inter-server
   protocol will rely on the capabilities provided by another protocol,
   the Server Cache Synchronization Protocol (SCSP) [2].  The SCSP
   protocol defines a generic capability for the replication of
   multiple, dispersed, replica server databases.  The SCSP places no
   topological requirements on the interconnection of the replica
   databases other than the requirement that the resultant graph spans
   the total set of servers. The SCSP protocol itself borrows heavily
   from the work of link state protocol database replication.

   The DHCP inter-server protocol uses TCP between pairs of servers.
   Each server is configured with a list of all other servers. The
   servers are also all configured with a pool of candidate IP addresses
   that may be assigned dynamically to DHCP clients.  Periodically or on
   demand, a server may contact one, some or all other DHCP servers to
   perform DHCP inter-server protocol functions.  All DHCP servers have
   synchronized clocks (e.g., using NTP).  Through these protocol
   sessions between pairs of servers, a server can inform other servers
   about new bindings or about lease extensions on existing bindings and
   can inform other servers about bindings that have been released.

   The collection of bindings managed by the DHCP servers is essentially
   a distributed database.  The servers can use the inter-server
   protocol to synchronize changes to the database and ensure coherency
   among the individual servers.  However, latency in the
   synchronization process means that the bindings on some servers may
   be stale.  Potentially, clients could receive invalid configuration



Droms, Cole                                                     [Page 2]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   information based on these stale bindings.  The inter-server protocol
   is designed to ensure that clients always receive valid configuration
   information.


1.1  Terminology

   This document uses the following terms:

      + "DHCP client"

         A DHCP client is an Internet host using DHCP to obtain
         configuration parameters such as a network address.

      + "DHCP server"

         A DHCP server is an Internet host that returns configuration
         parameters to DHCP clients.

      + "binding"

         A binding is a collection of configuration parameters,
         including at least an IP address, associated with or "bound to"
         a DHCP client.  Bindings are managed by DHCP servers.

      + "Local Server"

         A Local Server (LS) references the particular server in
         question.

      + "Directly Connected Server"

         A Directly Connected Server (DCS) references servers which are
         directly connected to (or one hop removed from) the LS.

      + "Remote Server"

         A Remote Server (RS) references servers two or more hops
         removed from the LS.

      + "Server Group"

         A Server Group (SG) is the set of associated servers providing
         the redundant database for the common set of PCs, workstations,
         etc.

1.2  Protocol Goals




Droms, Cole                                                     [Page 3]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   The DHCP inter-server protocol is developed with the following
   objectives:

      + Develop a highly available DHCP server architecture.

      + Maintain the client behavior in the current non-redundant DHCP
      protocol [1].

      + Maintain the design goals of the DHCP Client/Server protocol as
      identified in [1].

      + Maintain uniqueness of the assigned IP addresses.

      + Minimize changes to the behavior of the BOOTP Relay Agents.

      + Ease redundant server administration.  Administration should be
      primarily isolated to a single server of the replica server group.
      Failure recovery should be automatic.


   The DHCP inter-server protocol provides the following functions:

      + Distribution of address assignment information,

      + Distribution of lease release (as a result of DHCPRELEASE)
            information,

      + Reallocation of available addresses and

      + Query about whether a specific address is "in use".



1.3  Approach Philosophy

   The remainder of the this document discusses the SCSP as applied the
   problem of developing the DHCP inter-server protocol.  Two redundant
   server behavior models are developed; the Peer Redundant Server Model
   (PRSM) where all servers are roughly equivalent in their actions and
   the Primary/Secondary Redundant Server Model (PSRSM) where the
   primary server handles all interaction with the DHCP clients.  Over
   time, one of the behavior models will be chosen and fully developed
   as the DHCP inter-server protocol.

   Section 2 of this document presents an overview of the SCSP protocol
   and a discussion of the issues to resolve in building the DHCP
   inter-server protocol on the SCSP capabilities.  The issues to be
   resolved include the decision on the choice of the redundant server



Droms, Cole                                                     [Page 4]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   behavior model for the DHCP inter-server protocol.  Section 3
   presents the Peer Redundant Server Model (PRSM) where all servers are
   roughly equivalent in their actions.  Section 4 presents the
   Primary/Secondary Redundant Server Model (PSRSM).  Here a primary
   server handles all the interaction with the DHCP clients, where
   changes to the client's binding are required.  Included in the
   discussion of the PRSM and the PSRSM is a description of the ways in
   which DHCP servers will use the protocol to coordinate assignment,
   release and expiration of bindings to guarantee consistent
   interactions between DHCP servers and clients.  These sections also
   contain a list of the open questions to resolve for the full
   development of the respective models.  We anticipate that this list
   of open questions will be resolved in following drafts.  Section 5
   presents the DHCP specific Client State Advertisement and Client
   State Advertisement Summary records.  These are required to map the
   DHCP inter-server protocol onto the SCSP capabilities.  Section 6
   contains conclusions.


2.  Analysis of SCSP for DHCP Inter-server Protocol

   This section presents a brief overview of the SCSP protocol.  Further
   details are found in the appendices and in Reference [2]. An analysis
   of the issues to resolve to build the DHCP inter-server protocol on
   top of the SCSP capabilities is presented following the SCSP
   Overview.

2.1  SCSP Overview

   The SCSP protocol consist of three separate sub-protocols, i.e.,

      the status of the inter-server connection,

      + the "Cache Alignment" protocol: this protocol defines the cache
      synchronization capability for new servers and servers that, for
      whatever reason, have lost synchronization, and

      + the "Client State Update" protocol: this protocol provides the
      ongoing server cache synchronization through asynchronous client
      state updates.

   These sub-protocols define the semantics and high-level syntax of
   generic message sets and their exchanges in support of the
   capabilities provided.  The SCSP associates replica databases into
   Server Groups.  The SCSP supports both point-to-point and point-to-
   multipoint connections between the LS and the DCS(es).  We discuss
   each of these sub-protocols in more detail in the appendices below.




Droms, Cole                                                     [Page 5]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   For now we accept that these capabilities are generically provided
   and analyze possible redundant DHCP server overlays on top of the
   SCSP.  Within DHCP, the notion of SCSP Server Groups (SG) is defined
   by those servers supporting a common set of client PCs, workstations,
   etc.  Then, in general we have multiple redundant servers supporting
   distinct sets of client PCs which may be remote from their supporting
   servers.  Logically, the remote PCs are connected to their
   geographically dispersed servers via DHCP relay agents and IP
   transport.  The relay agents may have multiple interfaces to the
   network.

   For discussion purposes we say that SG A supports the client base A,
   SG B supports the client base B and so on.  Relay agents A1, A2,
   servers A1, A2, ...


2.2 Issues to Resolve for DHCP Inter-server Protocol Development

   The SCSP does not fully define the redundant DHCP inter-server
   protocol.  It does provide an underlying capability. Several issues
   must by addressed in order to fully define the DHCP inter-server
   protocol.  These include:

      + What behavior model will the redundant servers within a SG
      employ?

      + Can the DHCP inter-server protocol be developed without
      modifying the behavior of the relay agents and the clients?

      + How do servers in the SG identify a "failed" server?

      + What are the DHCP protocol specific client state records defined
      in SCSP?

      + How does SCSP support the synchronization of pre-configured (or
      provisioned) database information?

      + What is the nature of the server-to-server connection?

      + What topologies will be supported?

   We discuss each of these separately below.  Within each of the
   appendices, which present short overviews of the SCSP sub-protocols,
   further elaboration on some of the above issues is provided.


2.2.1 What behavior model will the redundant servers within a SG employ?




Droms, Cole                                                     [Page 6]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   Two distinct models are Peer Behavior and Primary/Secondary Behavior.
   These two models are more fully developed in Sections 3 and 4
   respectively.

2.2.2  How do servers in the SG identify a "failed" server?

   the LS know that the DCS is disconnected from the client pool
   associated with their SG?  Does the fact that the LS is disconnected
   from the DCS yet connected to the client pool indicate that the DCS
   is necessarily disconnected from the client pool?  I.e., does routing
   transitivity hold?

2.2.3 Can the DHCP inter-server protocol be developed without modifying
   the behavior of the relay agents and the clients?

   In particular, when a server fails and another server picks up its
   bindings, how does the client lease extensions, lease releases,etc.
   get to the new server?  Does the relay agent replicate the messages
   to all servers in a Server Group?  How do the servers within a single
   Server Group respond to client requests, discovery, extension,
   release?

   In [3] there is a discussion of a Relay Agent caching an association
   between a client and a server for the duration of the lease to help
   provide some load sharing capabilities.  If this is in fact
   implemented, then the Relay Agent would have to move this to the
   backup server in the event the client server failed.

2.2.4 What are the DHCP protocol specific client state records defined
   in SCSP?

   The SCSP defines a generic message set and semantics and associated
   client state records.  The specifics of the DHCP bindings must be
   mapped into this message set and client records.  Specifically, it is
   required to define the DHCP protocol specific CSAS and CSA records
   which are part of the CA and CSU messages, respectively.  Loosely,
   the CSA record within a DHCP implementation is the client binding and
   the CSAS is a summary message and pointer to the CSA on the
   originating server.

2.2.5 How does SCSP support the synchronization of pre-configured (or
   provisioned) database information?

   The Client State Advertisement (and Summary) records are explicitly
   defined to support client requested bindings (or summaries).  But
   there is information provisioned into DHCP servers which must be
   distributed to a new replica server.  How this information is
   replicated needs definition within the DHCP inter-server protocol



Droms, Cole                                                     [Page 7]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   through the exchange of SCSP messages.

2.2.6 What is the nature of the server-to-server connection?

   SCSP was developed within the ION working group and relies on an
   underlying layer two connection existing.  What is the nature of the
   corresponding connection for the DHCP server-to-server case?  Is it
   none, i.e., simple UDP/IP connectivity?  (Are the acknowledgment and
   timeout procedures within SCSP robust enough to run over UDP?)  Or is
   it a TCP connection?  (Need to define a TCP port number or dynamic
   assignment of the port for this protocol to run over.)

2.2.7 What topologies will be supported?

   The SCSP supports both point-to-multipoint and point-to-point
   connections between the LS and the DCS.  It also supports full mesh
   and a partial mesh interconnection of servers within an SG.  What
   impact on the system performance will these different topologies
   have?

   Each of the above issues must be addressed for the DHCP inter-server
   protocol independent of use the generic capabilities offered by SCSP.
   The value of the SCSP is that it provides the lower level connection
   maintenance, database synchronization and asynchronous database
   update capabilities that are required of any redundant server
   architecture.  By relying on SCSP as the lower level synchronization
   capabilities, the work of defining the DHCP inter-server protocol is
   greatly simplified.  This simplification would allow the working
   group to focus on resolving the DHCP inter-server protocol specific
   issues identified above, having the effect of accelerating the
   progress of this protocol development.


3.  Peer Redundant Server Models

   In the Peer Redundant Server Model (PRSM) all servers of the SG
   behave roughly identically.  Each can respond to the initial
   DHCPREQUESTs of the clients, each is the owner of their particular
   bindings, etc.  They all are capable of randomly servicing clients
   from a pool and all are responsible to propagate the binding
   information within the SG.  This model has the advantages that it
   provides load balancing and a graceful fault recovery (once defined).
   It has the disadvantages that it is harder to ensure non-duplicate
   address assignments and the client bindings are distributed
   potentially making fault isolation more difficult.


3.1 PRSM Description



Droms, Cole                                                     [Page 8]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   The PRSM supports multiple servers within a single SG.  Within the SG
   the actions and behavior of all servers are roughly equivalent to one
   another.  Any of the servers can handle the DHCP client server
   interactions.  The servers within the SG maintain sufficient TCP
   connectivity that the resultant graph spans the set of servers in the
   SG.  All DHCP servers within the SG have synchronized clocks, e.g.,
   using NTP.  The Relay Agents forward messages to all servers in the
   SG.

   The approach proposed for the PRSM, which we believe is conceptually
   the easiest to develop, is that 1) unallocated addresses belong to
   different servers (however, they can be redistributed through the
   Address Redistribution Procedure), and 2) once a binding is made, and
   for the duration of that binding, it 'belongs' to that server (unless
   the server dies or becomes disconnected for its set of clients).
   States in which the bound client unicasts back to that server are
   handled sufficiently well with this approach.  (Note: There are
   probably failure scenarios where the client unicasts back, e.g.,
   sends a DHCPDECLINE from the REQUESTING-state or a DHCPRELEASE from
   the BOUND-state, to a server which has recently died that need to be
   thought through in some detail.)  Client states where the bound
   client broadcast back to the SG are handed somewhat differently.  In
   this case, only the owner of the binding should respond if a change
   to the binding is requested, e.g., a lease extension.  If a change to
   the binding is not required, e.g., the client is in the INIT-REBOOT-
   state and is only verifying an existing binding, then any of the
   servers may respond.

   When a server dies (or becomes disconnected), the bindings (and
   unallocated address) belonging to it are passed to another server of
   the SG according to some rule.  The rule could be a simple list
   administered into the definition of the SG which defines which server
   is to pick up the bindings belonging to the dead (or disconnected)
   server.  (We suspect that this new server should change the and
   should propagate these new CSA records to the other servers in the
   SG.)  Therefore, this model relies on the notion of server
   'ownership' of the client binding.  The ownership is communicated
   through the

   Prior to committing any change to a client binding, e.g., sending a
   DHCPACK, the LS must communicate this information with at least one
   DCS in the SG.  This may cause excessive delay in servicing DHCP
   client requests.  However, this is necessary to guarantee that no
   duplicate address assignments occur.  The advantage of requiring
   forwarding to only one backup server is that this scales well as the
   number of servers in a SG grows; you do not have to forward to all
   servers in a SG.  There are performance improvements possible in an
   implementation, e.g., your could forward to two, but wait for the



Droms, Cole                                                     [Page 9]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   acknowledgment from only one.  Therefore, if you are running this
   protocol over noisy facilities, this would improve the probability of
   getting the forwarding out to at least one other server the first
   time.

   When a server boots and establishes connectivity to the other servers
   in the SG or re-establishes connectivity to other servers in the SG,
   it synchronizes its cache according to the cache alignment protocol
   as describe in [2].

   When a server looses connectivity to another server, it should check
   to see if it is picking up the ownership of the dead server.  If so,
   it should appropriately modify the CSA records associated with the
   dead server.  It should then force the SCSP cache alignment process
   with each of its remaining DCS prior to servicing any further client
   messages.  (Note: we're assuming there a mechanism to force the cache
   alignment process?)

   The available address pool is distributed over the peer servers in
   the server group.  Each unallocated address 'belongs' to a specific
   server.  The Address Redistribution Procedure distributes unallocated
   addresses to the peer servers.  If a server runs low of unallocated
   addresses it can request additional unallocated addresses through the
   Address Redistribution Procedure.  If it is out of unallocated
   addresses, it must obtain more before it can make DHCPOFFERS.  This
   effectively decouples the servicing of clients from the request for
   unallocated addresses and should provide better performance and
   scaling.

   In the event of a server failure, the unallocated addresses
   associated with the failed server must be available to another server
   or servers in the SG.  These addresses are passed to another server
   in the server group along with the bindings which belonged to the
   failed server according to a rule as discussed above.  Unallocated
   addresses are redistributed by the Address Redistribution Procedure
   on a need be basis.  The Address Redistribution Procedure is TBD.

3.2 Protocol actions

   There are several DHCP protocol interactions that can change the
   address assignment information managed by DHCP servers:

      + New address assignment

      + Lease extension

      + Lease expiration




Droms, Cole                                                    [Page 10]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      + RELEASE

   In the remainder of this section, each case is discussed along with
   PRSM actions to avoid passing invalid configuration information to
   clients.  Server actions which do not change the nature of a binding,
   e.g., binding verification requests from a client in the INIT-
   REBOOT-state, can be serviced by any of the servers in the SG.

3.2.1 New Address Assignment

   When a DHCP server assigns a new IP address to a DHCP client (as part
   of an INIT-state transaction), the server adds that assignment to its
   local database of bindings.  The server must use an IP address that
   is available for assignment from its local address pool and must
   inform at least one of the other DHCP servers about the newly created
   binding by completing the transmission of a CSU message containing
   the CSA record to the other server or servers. These actions must be
   completed just prior to sending the DHCPACK.  The SCSP protocol
   requires the DCS(s) to forward this CSU throughout the remainder of
   the SG.  (Note:  Specify the options/type/priority fields in the CSA
   message.)

   To identify an IP address that may be assigned to the new client, the
   server picks an address from its local pool of assignable addresses
   (as described in the Address Redistribution Procedure) that is not
   currently in the server's list of bindings.  If the server is 'low'
   on available address for assignment, it should initiate the Address
   Reassignment Procedure (soon after servicing the immediate client
   request) in order to obtain additional address.  If no addresses are
   available for local assignment, no DHCPOFFER can be sent to the
   client.


3.2.2 Lease Renewal

   A DHCP server may choose to extend the lease of a DHCP client in
   response to a DHCPREQUEST message from a client in INIT-REBOOT-state.
   This server must be the 'owner' of the client binding.  This lease
   extension is propagated by the extending server to at least one other
   server by successfully transmitting a CSU message containing the CSA
   record with the lease extension.  This must happen prior to the
   server transmitting the DHCPACK to the client.  The SCSP protocol
   ensures the propagation of this information to all servers in the SG.


      DISCUSSION:

      The details of this propagation require a little care in their



Droms, Cole                                                    [Page 11]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      design.  The delay between lease extension and distribution to
      other servers leaves a window in which some servers may have
      different lease expiration times for a particular binding.  During
      that window, a client may reboot and get an old lease expiration
      date or a server may determine that a lease has expired (based on
      an old lease expiration date) after it has been extended on
      another server.

      If a client receives an old expiration date (that has not been
      extended), the client will reset its expiration date to that old
      value.  If the lease is sufficiently close to expiring, the client
      will use DHCP to extend the lease.  Even if this extension takes
      place on a different server, the servers will eventually converge
      to agree on the expiration time last issued to the client.

      A server may determine that a lease has expired prior to
      notification of the extension of that lease.  If the server takes
      no explicit action other than to delete the expired binding from
      its database, the extended lease will propagate to the server from
      the extending server.  The following section describes lease
      expiration in more detail.

      It is hoped that this issue can be resolved by employing the
      notion of binding ownership, e.g., lease extensions should not
      happen without explicit communication with the server currently
      owning the CSA record.  The details need to be worked out and
      changes to this section made.

3.2.3 Lease Expiration

   When a DHCP server determines that the lease on a binding has
   expired, the server simply drops that binding from its database and
   takes no other explicit action.  The address in that binding is
   available to be allocated to another client at this time by the
   server owning that unallocated address.

      DISCUSSION:

      If a server takes no other specific action than to delete the
      binding from its database, premature expiration (expiration based
      on a stale expiration date) will have no effect.  The extending
      server will distribute the information about the lease extension
      to the other servers, synchronizing all of the other servers to
      the new expiration date.

      The only potential problem arising from premature expiration is
      reassignment of an address that is still in use.  The notion that
      a server owns the client binding and the associated address should



Droms, Cole                                                    [Page 12]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      eliminate the possibility of this situations from occurring.

3.2.4 Lease RELEASE

   When a DHCP server receives a DHCPRELEASE from a client and the
   server is the owner of that client binding, the server should expire
   that binding and transmit a CSU message containing the CSA record of
   the release notification to at least one of the other servers in the
   SG.  The other servers discard the binding record from their
   databases upon receipt of the CSA record containing the DHCPRELEASE
   notification.

   If the RELEASEing server discovers any other server that has
   responded to a DHCPREQUEST message from the DHCP client for the
   RELEASEd address after the RELEASE message was received, the client
   is still using the address and the lease is still valid.  In this
   case, the server that has responded to the DHCPREQUEST message
   retains the ownership of the binding and distributes that binding to
   at least one of the other servers.

      DISCUSSION:

      The case discussed in the second paragraph is actually a DHCP
      protocol error on the part of the client; after issuing a
      DHCPRELEASE, the client MUST go to INIT-state and request a new
      address.  However, as there is no mechanism in DHCP through which
      the server can inform the client of such an error, the servers
      must accommodate the error and maintain the consistency of the
      binding database.

      In the event that the original server has died prior to receiving
      a RELEASE message from the client, the RELEASE message will not be
      propagated to the remaining servers. This is due to the fact that
      the RELEASEing client unicasts the message to the dead server.
      The implications of this need to be fully determined.  Currently,
      no actions are defined to try to 'capture' the client RELEASE by
      another server in the SG.


3.3 Address Redistribution Procedure

   This procedure is TBD.

   Several requirements imposed on this procedure are identified in the
   above PRSM.  These include:

      + The redistribution procedure must be capable of distributing the
      unallocated addresses at SG initialization or when initializing a



Droms, Cole                                                    [Page 13]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      new server of the SG.

      + The redistribution procedure should fairly distribute
      unallocated addresses.


      DISCUSSION:

      The Address Redistribution Procedure has not been fully thought
      out.  However, the procedure may be as simple as the following
      algorithm.  A server which realizes that it is low on unallocated
      addresses (associated with a given subnet), may initiate a request
      to DCS(s) for more unallocated addresses.  A server may find
      itself in this situation either at initialization time, reboot, or
      by allocating most of its owned addresses.  The server then goes
      down its list of DCS(s).  For each DCS, the LS sends a request for
      additional addresses.  Contained in this request is the number of
      unallocated addresses it currently owns, say n.  The receiving DCS
      compares this to its number of unallocated addresses, say m.  If m
      > n, then the DCS must respond to the LS with (m - n)/2 addresses.
      If m < n, then the DCS may request the LS to provide it with (n -
      m)/2 addresses.  The LS continues this procedure until it has
      corresponded with each of its DCS(s).

      To avoid situations/conditions where addresses are sparse and
      potential battles for addresses would occur, there probably needs
      to be some sort of throttling mechanism to slow down the requests.

3.4 Open Questions for the PRSMs

      + Are these the only cases in which binding information may become
           out of date?

      + Are these solutions correct?

      + Need to fully develop procedures for DHCPDECLINE, DHCPRELEASE
      and all 'lost' packet and failure scenarios.

      + Servers cooperating to achieve "fair" distribution of available
      addresses through the Address Redistribution Procedure.

      + Can a cache alignment process be 'simultaneously' imposed on all
      servers in the SG?
         The philosophical approach taken in defining the actions of the
         assigning server is to force it to inject the information into
         at least one other server in the SG just prior to committing a
         change in a client state, e.g., an IP address assignment, a
         lease extension, etc.  Then, force all servers to go into a



Droms, Cole                                                    [Page 14]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


         'simultaneous' cache alignment process in the event of a server
         failure in the group to ensure that the most recent CSA records
         are fully propagated prior to further assignments or extensions
         being made by the group.  This is to ensure non-duplicate
         address assignments.  But the specifics of how to force a
         'simultaneous' cache alignment is to be determined.

      + User intervention in case of database incoherency
         Fixing the collective database on the DHCP servers in case of a
         problem could be a *real* nightmare.

      + DHCP server maintenance
         There is likely an opportunity for the development of a server
         management tool that would download the database information
         from all servers and check for conflicts/inconsistencies such
         as assignment of an IP address to multiple clients, bindings
         that are not replicated across all servers, bindings that have
         inconsistent lease expiration times, etc.


4.  Primary/Secondary Redundant Server Models

   In the Primary/Secondary Behavior model, a single server in the SG is
   primary and is responsible for servicing all client PCs and to
   distribute this information to the other servers.  All other servers
   are secondary.  Secondary servers may participate in client/server
   interactions when no modification to an existing binding is required,
   e.g., a client verification request.  When the primary server fails,
   one of the secondary servers becomes the new prime. One mechanism to
   elect the primary server within an SG is described in Appendix C of
   [2].  Another mechanism is to simply define through an administrative
   rule the order of ascension.  Currently, the Primary Election Process
   for the PSRSM is to be determined.

   This model has the advantage of being conceptually simple to discuss,
   minimizes issues associated with duplicate address assignments and
   isolates the ownership of the bindings to a single server at any
   point in time. It has the disadvantages of not fully supporting load
   balancing.

4.1  PSRSM Description

   The PSRSM supports multiple servers within a single SG.  Within the
   SG a single server acts as the "Primary" server; all other servers
   act as "Secondary" servers. The Primary server is responsible for
   handling all DHCP client server interactions which require a change
   to a client binding. The role of the secondary servers is to maintain
   a redundant server cache in the event that the primary server fails.



Droms, Cole                                                    [Page 15]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   However, if a change to the binding is not required, e.g., the client
   is in the INIT-REBOOT-state and is only verifying an existing
   binding, then any of the secondary servers may respond as well.  The
   servers within the SG maintain sufficient TCP connectivity that the
   resultant graph spans the set of servers in the SG.  All DHCP servers
   within the SG have synchronized clocks, e.g., using NTP.  The Relay
   Agents forward messages to all servers in the SG.

   Prior to committing to any change in a client binding, e.g., sending
   a DHCPACK, the Primary server must communicate this change to at
   least one secondary DCS.  This may cause excessive delay in servicing
   DHCP client requests.  However, this is necessary to guarantee that
   no duplicate address assignments occur.  The advantage of requiring
   forwarding to only one backup server is that this scales well as the
   number of servers in a SG grows; you do not have to forward to all
   servers in a SG. There are performance improvements possible in an
   implementation, e.g., your could forward to two, but wait for the
   acknowledgment from only one. Therefore, if you are running this
   protocol over noisy facilities, this would improve the probability of
   getting the forwarding out to at least one other server the first
   time.

   Within this model, ownership of a client binding always resides with
   the Primary server.  Because the Primary server is solely responsible
   for the servicing of all client requests which require changes to be
   made to the client binding, it can potentially represent a
   performance bottleneck. A possible solution to this problem is to
   limit the number of subnets (and hosts) supported by a SG in the
   PSRSM.  However, in situations where the majority of the
   client/server interactions are related to verification of existing
   bindings, load balancing can occur because the secondary servers may
   respond to these client requests as well as the primary server.

   When a server boots and establishes connectivity to the other servers
   in the SG or re-establishes connectivity to other servers in the SG,
   it synchronizes its cache as describe in [2].  A newly established
   (or reconnected) server within the SG can initiate the Primary Server
   Election Process. The Primary Server Election Process is TBD (one
   such election process is discussed in the Appendix C of [2].)

   When a secondary server or group of secondary servers become
   disconnected from the primary server (for whatever reason), they
   initiate the Primary Server Election Process.  The servers can be
   disconnected for many reasons, e.g., a failure of the primary server
   process or a network failure causing the connection to be dropped.
   When a secondary server becomes disconnected from other secondary
   servers this is not cause to initiate the Primary Server Election
   Process.  Once the primary server is newly elected, it should go



Droms, Cole                                                    [Page 16]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   through the SCSP cache alignment protocol with each of the remaining
   secondary servers prior to servicing client messages.  (Note: we're
   assuming there a mechanism to force the cache alignment process?)
   (Note: There are probably failure scenarios where the client unicasts
   back, e.g., sends a DHCPDECLINE from the REQUESTING-state or a
   DHCPRELEASE from the BOUND-state, to a server which has recently died
   that need to be thought through in some detail.)


4.2  Protocol Actions

   There are several DHCP protocol interactions that can change the
   address assignment information managed by DHCP servers:

      + New address assignment

      + Lease extension

      + Lease expiration

      + RELEASE

   In the remainder of this section, each case is discussed along with
   PSRSM inter-server protocol actions to avoid passing invalid
   configuration information to clients. Server actions which do not
   change the nature of a binding, e.g., binding verification requests
   from a client in the INIT-REBOOT-state, can be serviced by any of the
   servers in the SG.

4.2.1  New Address Assignment

   Just prior to sending the DHCPACK, the primary server completes the
   transmission of a CSU message containing the CSA record for the
   client binding to at least one of the secondary DCSs.  The SCSP
   protocol requires the DCS(s) to forward this CSU throughout the
   remainder of the SG.  (Note:  Specify the options/type/priority
   fields in the CSA message.)

   If a newly elected Primary server receives a DHCPREQUEST with a
   'server identifier' other than its own, it should respond to this
   DHCPREQUEST. (How would this currently happen?)

4.2.2  Lease Renewal

   Just prior to sending the DHCPACK, the primary server completes the
   transmission of a CSU message containing the CSAS record for the
   renewed client binding to at least one of the secondary DCSs.  The
   SCSP protocol requires the DCS(s) to forward this CSU throughout the



Droms, Cole                                                    [Page 17]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   remainder of the SG.  (Note:  Specify the options/type/priority
   fields in the CSA message.)

4.2.3  Lease Expiration

   When the primary server determines that the lease on a binding has
   expired, the server simply drops that binding from its database and
   takes no other explicit action.  The address in that binding may be
   assigned to a new client at this time. When a secondary server
   determines that the lease on a binding has expired, the server simply
   drops that binding from its database and takes no other explicit
   action.

4.2.4  Lease RELEASE

   When a primary server receives a DHCPRELEASE from a client, the
   primary server completes the transmission of a CSU message containing
   the CSAS record for the released client binding to at least one of
   the secondary DCSs.  The servers discard the lease from their
   databases.

      DISCUSSION:

      There are probably failure scenarios where the client unicasts
      back, e.g., sends a DHCPDECLINE from the REQUESTING-state or a
      DHCPRELEASE from the BOUND-state, to a server which has recently
      died that need to be thought through in some detail.  In this
      case, there is no mechanism currently defined for the newly
      elected primary server to receive the client's RELEASE message.


4.3  Primary Server Election Process

   The Primary Server Election Process is to be determined.


      DISCUSSION:

      However, this may be as simple as defining an 'administrative
      rule' to determine the order of succession (as discussed above in
      the case of passing binding ownership in the PRSM above).  Or this
      may be more automatic through the definition of an election
      process, such as that identified in the appendix of [2].

4.4  Open Questions for the PSRSM

      + Can a cache alignment process be 'simultaneously' imposed on all
      servers in the SG?



Droms, Cole                                                    [Page 18]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


         The philosophical approach taken in defining the actions of the
         assigning primary server is to force it to inject the
         information into at least one other server in the SG just prior
         to committing a change in a client state, e.g., an IP address
         assignment, a lease extension, etc.  Then, force all servers to
         go into a 'simultaneous' cache alignment process in the event
         of a primary server failure in the group to ensure that the
         most recent CSA records are fully propagated prior to further
         assignments or extensions being made by the group.  This is to
         ensure non-duplicate address assignments.  But the specifics of
         how to force a 'simultaneous' cache alignment is to be
         determined.

      + Need to define the new primary server election process.

      + Need to fully develop procedures for DHCPDECLINE and all 'lost'
      packet scenarios and failure scenarios.


5. DHCP Specific CSA and CSAS Records

   This section presents the CSA and the CSAS records specific to the
   DHCP inter-server protocol. These records apply to both the PRSM and
   the PSRSM and so are presented separately in this section.

   The assumptions made in defining the DHCP client/server protocol
   specific records are the following:

      + Must provide the capability for the auto-configuration of a new
      server.  One ancillary use of the inter-server protocol is in
      configuring new DHCP servers. The DHCP inter-server protocol
      should allow the download of a server's configuration file and to
      allow addition of a new server to the list of DHCP servers.  A new
      server might be configured by simply giving it the address of an
      existing server. The new server could then download a list of all
      other known servers, the pool of candidate addresses, any special
      configuration information (e.g., vendor class information) and the
      existing bindings. The new server could also announce itself to
      all of the other existing servers.

      + A 'boot record' is required which carries the provisioned
      portion of the DCHP server cache.  This is the information which
      contains the administrative information defining the address
      range, 'scopes', registered clients', etc.  It is assumed that
      this record is vendor specific (because of the different
      implementations of the server configuration files) and will be
      defined as such.  This boot record will satisfy the capabilities
      discussed in the previous bullet item. (Note: this requires a lot



Droms, Cole                                                    [Page 19]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      more thought.)

      + The CSAS and the CSA records are maximally defined at this
      point.  Because clients DHCPDISCOVERY messages can contain client
      specific requests for parameters, it is necessary to embed the
      full set of options (committed to the client in the DHCPOFFER
      message) within the CSA record.  If it is determined at a later
      date, that there is information in the CSA records which are
      locally derivable, then this information will be removed from the
      definition of the CSA records.

5.1  CSAS Records

   According to the semantics of the CSAS record defined in [2], the
   CSAS record should maximally contain the 'CSA Sequence Number', the
   'Search String' and the server 'Originator ID'.  Further, the
   sequence number is defined in the generic portion of the CSAS record;
   only the search string and the originator ID are DHCP protocol
   specific.

   The format of the CSAS record for the DCHP inter-server protocol is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    CSA Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |type |  state  |   htype       |    hlen       |   reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       chaddr  (16 octets)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ciaddr                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Server ID (encoded as in BOOTP options, tag=54) (6 octets)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional ClientID (encoded as tag=61) (variable)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   End Option (encoded as in BOOTP options, tag=255) (1 octet) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Figure 5.1-1  DHCP inter-server CSAS record format
   where

      CSA Seq.No - is part of the generic SCSP CSAS record format
      defined in [2]

      type - represents the type of the CSAS record, e.g. client, boot



Droms, Cole                                                    [Page 20]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      state - represent the state of the (client) record, e.g.,
      reserved, unbound, bound, extended

      htype - hardware address type (defined in [4])

      hlen - hardware address length

      chaddr - client hardware address

      ciaddr - client IP address (if assigned).  If not assigned, this
      field is all 0s.

      Server ID - the Server ID encoded as in the DHCP options and BOOTP
      vendor extensions defined in [3].

      (Optional) Client ID - this field is the optional Client ID
      encoded as in the DHCP options and BOOTP vendor extensions defined
      in [3]. If present, the Client ID is the 'search string'.

      End option - determines the end of the CSAS record

   The CSA sequence number is part of the generic CSAS record defined in
   [2].  The remainder of the CSAS record is the client/server protocol
   specific portion of the record.  The portion beginning with the
   Server ID is encoded as defined in the DHCP Options and BOOTP Vendor
   Extensions in [3] using a 'tag, length, variable' encoding scheme.

      DISCUSSION:

      The inclusion of the 'type' and 'state' fields needs more thought.
      There is a desire to provide the capability to dynamically
      propagate boot files between servers.  There are probably other
      ways to indicate the fact that the CSAS records points to a 'boot
      file' versus a 'client record', but it is felt that this is the
      most straight forward.

      The record identified above is really meant to represent the
      format for a 'client record', not the 'boot file' record. However,
      the format of the 'boot file' record is to be determined.  The
      SCSP CSA record supports fragmentation (with a fragmentation
      sequence number field of 15 bits).  Therefore, a CSA record could
      accommodate a large boot file transfer.

      The 'state' filed was included currently as a place holder.  There
      may be a need to be able to explicitly identify the state of a
      client record.  This field is placed here in anticipation of this
      requirement.




Droms, Cole                                                    [Page 21]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      The SCSP requires only the 'search string', the sequence number
      and the Originator ID (here the Server ID). The Client ID option
      was included because it is allowed in the DHCP protocol and is
      used as the 'search string' if it is included.  The default
      'search string' is the chaddr plus ciaddr combination.  In the
      event that the ciaddr is not assigned to the client, this field is
      all 0s.

5.2  CSA Records

   The format of the CSA record for the DCHP inter-server protocol is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|      Fragment Number        |           TTL                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    CSA Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Server Group ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |type |  state  |   htype       |    hlen       |   reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       chaddr  (16 octets)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       ciaddr                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Lease Time Stamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Server ID (encoded as in BOOTP options, tag=54) (6 octets)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     IP Address Lease Time (encoded as tag=51) (6 octet)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional ClientID (encoded as tag=61) (variable)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   End Option (encoded as in BOOTP options, tag=255) (1 octet) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             Figure 5.2-1  DHCP inter-server CSA record format
   where

      F - final bit, used to indicate the last fragment of a record

      Fragment Number - sequence number of the various fragments of a
      fragmented CSA record

      TTL - time to leave for a packet.  This represents the number of



Droms, Cole                                                    [Page 22]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      hops that a CSA takes before it is dropped.  At each server that
      the CSA record traverses, the TTL is decremented by one.

      CSA Seq.No - is part of the generic SCSP CSAS record format
      defined in [2]

      Server Group ID - a 32-bit identification field that uniquely
      identifies both the client/server protocol for which the servers
      of the SG are being synchronized, e.g., DHCP, as well as the
      instance of that protocol.  This implies that multiple instances
      of that same protocol may be in operation at the same time and
      have their servers synchronized independently of each other.

      type - represents the type of the CSAS record, e.g. client, boot

      state - represent the state of the (client) record, e.g.,
      reserved, unbound, bound, extended

      htype - hardware address type (defined in [4])

      hlen - hardware address length

      chaddr - client hardware address

      ciaddr - client IP address (if assigned).  If not assigned, this
      field is all 0s.

      Lease Time Stamp - a time stamp indicating when the lease was made
      to the client.  The specifics of this field are to be determined.
      The intent of this field is to allow another server (e.g., a newly
      booting server) to be able to determine the time this client's
      leave should expire (given as the sum of the Lease Time Stamp and
      the IP Address Lease Time below).

      Server ID - the Server ID encoded as in the DHCP options and BOOTP
      vendor extensions defined in [3]

      IP Address Lease Time - the IP Address Lease Time encoded as in
      the DHCP options and BOOTP vendor extensions defined in [3]

      (Optional) Client ID - this filed is the optional Client ID
      encoded as in the DHCP options and BOOTP vendor extensions defined
      in RFC 1533. If present, the Client ID is the 'search string'.

      Remaining Options - any remaining options carried in the original
      DHCPOFFER message to the client encoded as in the DHCP options and
      BOOTP vendor extensions defined in [3]




Droms, Cole                                                    [Page 23]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      End option - determines the end of the CSAS record

   The F-bit, Fragmentation Number, TTL, CSA sequence number and Server
   Group ID are part of the generic CSA record defined in [2].  The
   remainder of the CSA record is the client/server protocol specific
   portion of the record.  The portion beginning with the Server ID is
   encoded as defined in the DHCP Options and BOOTP Vendor Extensions in
   [3] using a 'tag, length, variable' encoding scheme.

      DISCUSSION:

      As discussed in the previous section on the CSAS record format,
      the format shown above is intended to be the client-type CSA
      record. Given a desire to support automatic booting of new servers
      and that the intent here is to support this boot file exchange
      through the CSA record, the definition of the bootfile-type CSA
      record needs to be defined.  This will probably be vendor specific
      and will probably rely on the fragmentation capability of the CSA
      record provided for in the SCSP [2].


5.3  Open Questions with the CSAS and CSA Records

   The following questions are identified as outstanding issues to be
   resolved for the CSAS and CSA record definitions to be considered
   complete:

      + Is the right approach for new server boot file transfers to rely
      on the CSA records defined within the SCSP?

      + Is it necessary to communicate the 'state' field information in
      the CSAS and CSA records?

      + How should the Lease Time Stamp be encoded?




6. Conclusion

   To be determined.


Appendix A:  The SCSP "Hello" Sub-protocol Overview

   The function of the SCSP "Hello" protocol is to monitor the status of
   the LS to DCS connection.  The LS must be configured with the
   addresses of its DCSs.  For each DCS (whether the low level



Droms, Cole                                                    [Page 24]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   connection is point-to-point or point-to-multipoint), the LS
   maintains an Hello Finite State Machine (HFSM).  The HFSM  is shown
   in the figure below.

                          +---------------+
                          |               |
                 +-------@|     DOWN      |@-------+
                 |        |               |        |
                 |        +---------------+        |
                 |            |       @            |
                 |            |       |            |
                 |            |       |            |
                 |            |       |            |
                 |            @       |            |
                 |        +---------------+        |
                 |        |               |        |
                 |        |    WAITING    |        |
                 |     +--|               |--+     |
                 |     |  +---------------+  |     |
                 |     |    @           @    |     |
                 |     |    |           |    |     |
                 |     @    |           |    @     |
               +---------------+     +---------------+
               |  BIDIRECTION  |----@|  UNIDIRECTION |
               |               |     |               |
               |  CONNECTION   |@----|  CONNECTION   |
               +---------------+     +---------------+

                Figure A-1  The Hello Finite State Machine


   Key:

      1: Link layer connection is established

      2: Transition based upon the receipt of a Hello message (and
      whether the LS ID is found in the  Rec ID portion of the message

      3: Hello Interval * Dead Factor exceeded

      4: Loss of link layer connectivity

   The LS to DCS connections are initialized into the down state.  The
   numbers in the figure refer to the actions discussed in the Key that
   cause a transition in the HFSM.  The Hello protocol employs poll
   messages to monitor the status of the LS to DCS connections.  The
   format of the Hello message is shown below.




Droms, Cole                                                    [Page 25]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  LS ID |  RecID1, .....RecIDn |  Hello Int |   Dead Factor    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure A-2   Hello message format


   The first field contains the LS ID.  The following fields contain the
   ID s of the DCS s that the LS has received a Hello message from.  The
   LS' HFSM uses these ID s to determine the status of the HFSM for each
   of the DCS s.  Multiple DCS ID s are present in order to support
   point-to-multipoint connections.  The following field is the Polling
   Interval and the last field is a Dead Factor.  The product of the
   Polling Interval and the Dead Factor determines the length of time
   that the HFSM will hold open a connection without receiving a Hello
   from a peer DCS and transitioning the HFSM for that DCS to the Wait
   state.

   Issues to resolve for DHCP Server-to-Server Implementation:

      + The transition from the Down to the Wait state is made when the
      link level connection between the servers is made.  The DHCP
      inter-server protocol needs to generalize this trigger because the
      path between redundant DHCP servers may not be a link level
      virtual circuit.  Possible triggers include a) the establishment
      of a TCP session between the servers or b) the return of a ping
      off the distant server.



Appendix B: The SCSP "Cache Alignment" Sub-protocol Overview

   The Cache Alignment protocol supports the initial server cache
   synchronization process of an LS with its DCSs.  This process may
   occur at initial boot time of the server, at reconnect time of the
   server to the network, or other possible initialization or failure
   recovery scenarios.  Like the Hello protocol, the Cache Alignment
   (CA) protocol maintains a Cache Alignment Finite State Machine
   (CAFSM) for each of its DCSs to monitor the status of its cache
   alignment.  The figure below shows the CAFSM and indicates some of
   the triggers that would cause the state transitions to occur.










Droms, Cole                                                    [Page 26]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


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


             Figure B-1  Cache Alignment Finite State Machine


   Key:

      1: When HFSM reaches Bi-directional state

      2: HFSM transitions out of Bi-directional state




Droms, Cole                                                    [Page 27]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      3: Master/Slave relationship is established

      4: Once both LS and DCS exchange CA messages, both with O-bit set
      to 0, then CRL is complete

      5: E.g., Errored sequence number

      6: Full cache update achieved

   Each of the CAFSMs is coupled with the respective HFSMs in the LS.
   The CAFSM is initialized in the Down state.  It transitions to the
   Master/Slave Negotiation state when the corresponding HFSM
   transitions to the Bi-Directional state.  The CAFSM transitions back
   to the Down state in the event that the corresponding HFSM
   transitions out of the Bi-Directional state.

   In the Master/Slave state the LS-DCS pair negotiate who is to be the
   master of the connection during the cache alignment process.  In the
   Cache Summary state the LS/DCS pair exchange Client State
   Advertisement Summary (CSAS) records within the CA messages.  The
   servers use these message exchanges to build a Client State
   Advertisement Request List (CRL).  The CRL indicates the portions of
   the respective server caches that are out of alignment.  The cache
   mis-alignment (as indicated in the local CRL) is resolved in the
   Update Cache state where the servers exchange full client state
   information in CSA records within the CSU messages, only where mis-
   alignment occurs.  Once the CRL is resolved, the LS/DCS caches are
   aligned and the CAFSM transitions to the Aligned state.

   The protocol further defines the high-level syntax of a generic CA
   message.  This format is shown in the figure below.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  LS ID |  DCS ID |  CA Seq.No. |  M-bit  |  I-bit   |  O-bit  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure B-2  Cache Alignment (CA) message format


   The message format consists of a CA Header followed by zero or more
   Client State Advertisement Summary (CSAS) records.  The CA header
   consist of LS and DCS ID s , a Sequence Number, and an M, I, and O
   bits.  The M bit indicates the Master/Slave relationship, the I bit
   indicates that the Master/Slave relationship is being negotiated and
   the O bit indicates more messages are to be exchanged.

   Issues to resolve for DHCP Server-to-Server Implementation:




Droms, Cole                                                    [Page 28]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      The SCSP generic message syntax and semantics are defined, but not
      the detailed mappings required for the DHCP Server-to-Server
      implementation.  Messages to be defined include:

         - Client State Advertisement Summary (CSAS) records within the
         Cache Alignment messages

         - Client State Advertisement (CSA) records within the Client
         State Update (CSU ) messages

      + Need to define the set of triggers which initiated the Client
      Alignment Protocol?  Clearly on server boot initialization.  But
      how does a well behaving server determine that due to network
      topology changes that it needs to trigger the Client Alignment
      Protocol ?

      + When building the CRL, the LS has to be able to determine, based
      upon the CSAS messages, that a particular client record is "out-
      of-date"?  The SCSP defines the term "search string" which is the
      key word used to access the server cache, e.g., the client HW
      address for the DHCP implementation.  The CA header also contains
      a sequence number which is monotonically  increasing and is
      assigned by the originating LS (e.g., a primary DHCP server in the
      primary/secondary behavior model discussed above).  The
      determination of the client state record's quality has to be
      specified.



Appendix C: The SCSP "Client State Update" Sub-protocol Overview

   The purpose of the Client State Update (CSU) protocol is to provide a
   capability to constantly update the server caches through
   asynchronous CSU message exchanges.  These updates are necessary
   because the status of the clients are in constant flux.  Unlike the
   other two sub-protocols, the Client State Update protocol does not
   maintain a separate finite state machine.  Instead, the activity of
   this protocol is tied to the CAFSM.

   Each CSU can contain zero or more Client State Advertisement records.
   The LS may send and receive CSUs when the corresponding CAFSM is in
   either the Aligned or the Cache Update states.  The CSU protocol
   defines both CSU requests and reply messages.  As consistent
   throughout the definition of the SCSP, the CSU protocol supports both
   point-to-point and point-to-multipoint connections.

   Issues to resolve for DHCP Server-to-Server Implementation:




Droms, Cole                                                    [Page 29]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


      The specific format of the Client State Advertisement (CSA)
      records within the CSU messages need to be defined for the DHCP
      implementation.



References

   [1] Droms, R., "<draft-ietf-dhc-dhcp-09.txt", Work in progress,
   November 1996.

   [2]  Luciani, J., Armitage, G., Halpern, J., "Server Cache
   Synchronization Protocol (SCSP)",  draft-ieft-ion-scsp-01.txt.

   [3]  Alexander, S.,  Droms, R., "DHCP Options and BOOTP Vendor
   Extensions",  Internet RFC 1533, October 1993.

   [4]  Reynolds, J., Postel, J., "Assigned Numbers", Internet STD 2,
   Internet RFC 1340,  USC/Information Sciences Institute, July 1992.

   [5]  (reference to the NTP RFC?)



Security Considerations

   Not currently addressed - but needed.


Acknowledgments

   Many of the ideas in this proposal are due to Jeff Mogul, Greg
   Minshall, Rob Stevens, Walt Wimer, Ted Lemon, John Carlson, Phil
   West, Joel Halpern and the DHC working group.  additional
   discussions. Thanks to all who have contributed their ideas and
   participated in the discussion of the inter-server protocol.


Author's Address

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

   Phone: (717) 524-1145
   EMail: droms@bucknell.edu



Droms, Cole                                                    [Page 30]


DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997


   Robert G. Cole
   AT&T Laboratories
   Managed Network Solutions Division
   Rm. 3L-533
   101 Crawfords Corner Road
   Holmdel, NJ  07733

   Phone: (908) 949-1950
   EMail: rgc@qsun.att.com










































Droms, Cole                                                    [Page 31]


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