Network Working Group                                           R. Droms					      K. Kinnear
INTERNET DRAFT                                       Bucknell University				   American Internet Corporation
								 R. Cole
								AT&T MNS

                                                              March
								R. Droms
						     Bucknell University
							       July 1997
						    Expires August 1997 January 1998

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

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents docu-
   ments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups. Note that other groups may also distribute
   working work-
   ing 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 mate-
   rial 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 all of the DHCP
   servers must carry be configured with the same information about assigned
   IP addresses and parameters; i.e., all of the servers must be configured config-
   ured 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 auto-
   matic mechanism for synchronization of the bindings stored on a set
   of cooperating DHCP servers.  The underlying capabilities

   This draft is a direct extension of draft-ietf-dhc-
   interserver-00.txt, and represents the DHCP inter-server

DRAFT         Analysis merging of SCSP for DHCP Redundant Servers    15 Mar ideas from both

DRAFT							       July 1997

   draft-ietf-dhc-interserver-alt-00.txt and draft-ietf-dhc-
   interserver-01.txt.	The basic protocol required for multiple server cache replications are based
   upon semantics from draft-ietf-
   dhc-interserver-alt-00.txt were used with the Server Cache Synchronization Protocol (SCSP). underlying message map-
   ping to SCSP from draft-ietf-dhc-interserver-01.txt.  Considerable
   additional work has been included in this current draft in the area
   of protocol correctness, detailed work on mapping the protocol to
   SCSP, and organization of the draft itself.

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,
   all of the distributed DHCP servers' databases servers must be configured with the same information
   about assigned IP addresses and parameters; i.e.,
   client bindings all of the servers
   must be replicated in multiple server databases. 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.

   Much

   The remainder of this document is organized in the underlying capabilities provided by following sec-
   tions:

     2.  Goals and Requirements

	 Defines the DHCP inter-server
   protocol will rely on requirements and goals for the capabilities provided by another protocol, protocol.  Discusses
	 limitations of the Server Cache Synchronization Protocol (SCSP) [2].  The SCSP
   protocol defines protocol.  Also contains a generic capability for the replication definition of
   multiple, dispersed, replica server databases.  The SCSP places no
   topological requirements on
	 several classes of failures as well as a list of specific fail-
	 ures (which provide a useful common ground for discussion).

     3.  Overview

	 Discusses in a general way the interconnection content of the replica
   databases other than information com-
	 municated between servers implementing this protocol as well as
	 the requirement way that information is communicated.

	 Introduces the three aspects of the resultant graph spans protocol: client binding
	 management, address management, and group management.

DRAFT							       July 1997

	 Defines some key concepts surrounding the total set allowable "states" of servers. The SCSP protocol itself borrows heavily
   from
	 an IP address, including extensions critical to the work operation
	 of link state this protocol.

	 Gives a brief sketch of the actions required by this protocol database replication.

   The
	 for each DHCP inter-server protocol uses TCP between pairs of servers.
   Each server is configured with a list client request received by the server.

     4.  Client Binding Management

	 Discusses the fundamental messages used by this portion of all other servers. The
   servers the
	 protocol, and the ways in which these messages are also all configured with a pool of candidate IP addresses
   that may be assigned dynamically combined to DHCP clients.  Periodically or on
   demand, a server may contact one, some or all other DHCP servers
	 form higher level operations.	Required responses to
   perform DHCP inter-server protocol functions.  All incoming
	 client binding management requests are explained in this sec-
	 tion.	The required responses to incoming 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. client requests
	 are explained in Section 6 below.

     5.  Address Management

	 The collection of bindings managed fundamental messages used by the DHCP servers is essentially
   a distributed database.  The servers can use address management portion
	 of the inter-server protocol are explained, as well as how they are combined
	 into higher level operations.	The required responses to synchronize changes to the database and ensure coherency
   among the individual servers.  However, latency incom-
	 ing address management requests are explained in this section,
	 while the
   synchronization process means that the bindings on some servers may
   be stale.  Potentially, clients could receive invalid configuration

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

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

1.1  Terminology

   This document uses the following terms:

      + "DHCP client"

         A incoming DHCP client is an Internet host using requests
	 are explained in Section 6 below.

     6.  Actions in Response to DHCP Client Messages and Events

	 The required responses 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 incoming DHCP client.  Bindings client messages and
	 events are managed by DHCP servers.

      + "Local Server"

         A Local Server (LS) references the particular server discussed 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 this section.

     7.  Group (SG) is the set of associated servers providing
         the redundant database Management

	 The fundamental messages and their combination into higher
	 level operations for the common set of PCs, workstations,
         etc.

1.2  Protocol Goals

DRAFT         Analysis group management portion 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 proto-
	 col are explained.  The actions to take when receiving any of the DHCP Client/Server protocol
	 these messages as
      identified in [1].

      + Maintain uniqueness of the assigned IP addresses.

      + Minimize changes well as how to the behavior of the BOOTP Relay Agents.

      + Ease redundant server administration.  Administration should be
      primarily isolated utilize them to join or leave
	 a single server of the replica server group.
      Failure recovery should be automatic. group are explained.

     8.  SCSP Message Mapping

	 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 messages described in sections 4, 5, and

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

1.3  Approach Philosophy

   The remainder of the 7 are mapped into
	 underlying SCSP messages in this document discusses section.  This includes
	 detailed information on the format of each SCSP as applied message.

     9.  IP Address State Transition

	 This protocol expands 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 possible states for an IP address.
	 The new states are roughly equivalent described in their actions and
   the Primary/Secondary Redundant Server Model (PSRSM) where the
   primary server handles Section 3.3.  This section

DRAFT							       July 1997

	 describes 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 transitions between states in detail.

     10. Security

	 The security implications of this document presents an overview of draft are discussed in this
	 section.

     11. Open Questions

	 Poses open questions about the SCSP protocol protocol.  Some questions from
	 draft-ietf-dhc-interserver-00.txt are included verbatim with
	 answers and a discussion of the issues questions (and some answers) new to resolve in building the DHCP
   inter-server protocol on the this draft are
	 included as well.

     12. Acknowledgments

     13. References

     14. Author's Information

     A.  Appendix A: An Overview of SCSP capabilities.

1.1.  The issues to be
   resolved include the decision on the choice of the redundant server

DRAFT         Analysis Language of SCSP for DHCP Redundant Servers    15 Mar 1997

   behavior model for the DHCP inter-server protocol.  Section 3
   presents Requirements

   Throughout this document, the Peer Redundant Server Model (PRSM) where all servers words that 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 used to define the client's binding are required.  Included in the
   discussion sig-
   nificance of particular requirements are capitalized.  These words
   are:

     o "MUST"

       This word or the PRSM and adjective "REQUIRED" means that the PSRSM item is a description an
       absolute requirement of this specification.

     o "MUST NOT"

       This phrase means that 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 item is an absolute prohibition of
       this specification.

     o "SHOULD"

       This word or the open questions adjective "RECOMMENDED" means that there may
       exist valid reasons in particular circumstances to resolve for ignore this
       item, but the full
   development of implications should be understood and the respective models.  We anticipate case
       carefully weighed before choosing a different course.

     o "SHOULD NOT"

DRAFT							       July 1997

       This phrase means that this list
   of open questions will be resolved there may exist valid reasons in following drafts.  Section 5
   presents particu-
       lar circumstances when the DHCP specific Client State Advertisement listed behavior is acceptable or even
       useful, but the full implications should be understood and Client
   State Advertisement Summary records.  These are required the
       case carefully weighed before implementing any behavior described
       with this label.

     o "MAY"

       This word or the adjective "OPTIONAL" means that this item is
       truly optional.	One vendor may choose to map include the
   DHCP inter-server protocol onto item
       because a particular marketplace requires it or because it
       enhances the SCSP capabilities.  Section 6
   contains conclusions.

2.  Analysis of SCSP product, for DHCP Inter-server Protocol example; another vendor may omit the
       same item.

1.2.  Terminology

   This section presents a brief overview of document uses the SCSP protocol.  Further
   details are found in following terms:

     o "DHCP client"

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

     o "client"

       Whenever the appendices and term client is used in Reference [2]. An analysis
   of the issues this draft, it refers to resolve a
       DHCP client (and not a server communicating with another server
       using this protocol).

     o "DHCP server"

       A DHCP server is an Internet host that returns configuration
       parameters to build the DHCP inter-server protocol on
   top clients.

     o "binding"

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

     o "active server"

       An active server is presented following the SCSP
   Overview.

2.1  SCSP Overview

   The SCSP protocol consist one which is capable of three separate sub-protocols, i.e.,

      the status offering IP addresses
       to clients.

     o "stable storage"

DRAFT							       July 1997

       Every DHCP server is assumed to have some form of the inter-server connection,

      + the "Cache Alignment" protocol: what is called
       "stable storage".  Stable storage is used to hold information
       concerning IP address bindings (among other things) so that this protocol defines the cache
      synchronization capability for new servers and servers that, for
      whatever reason, have
       information is not lost synchronization, and

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

   These sub-protocols define failure which
       requires restart of the semantics server.

2.  Goals and high-level syntax Requirements

   There are several levels of
   generic message sets and their exchanges in support goals for this protocol.  There are a set
   of the
   capabilities provided.  The SCSP associates replica databases into
   Server Groups.  The SCSP supports both point-to-point requirements with which it must comply, and point-to-
   multipoint connections between then there are a set
   of goals for the LS protocol and the DCS(es).  We discuss
   each of these sub-protocols in more detail in the appendices below.

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

   For now we accept way that it is used that these capabilities are generically provided
   and analyze possible redundant DHCP server overlays listed
   in priority order.

2.1.  Requirements on top of the
   SCSP.  Within DHCP, the notion this Protocol

   The following list of SCSP Server Groups (SG) is defined requirements must be (and are) achieved by those servers supporting a common set of client PCs, workstations,
   etc.  Then, in general we have multiple redundant servers supporting
   distinct sets this
   protocol.

     1. Implementations of this protocol work with existing DHCP client PCs which may be remote from their supporting
   servers.  Logically,
	implementations based on the remote PCs are connected to their
   geographically dispersed servers via DHCP protocol [1].  It must work
	with today's clients!

     2. Implementation works with existing BOOTP 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 implementations.

     3. Can be specified with sufficient clarity that unique implementa-
	tions will work well together the client base B and so on.  Relay agents A1, A2,
   servers A1, A2, ...

2.2 Issues to Resolve for first time (e.g. DHCP Inter-server today
	largely meets this requirement).

     4. Work well with minimum of two and a maximum of 16 servers.

2.2.  Goals of this Protocol Development

   The SCSP does not fully define following are the redundant DHCP inter-server goals of this protocol.  It does provide an underlying capability. Several issues
   must by addressed  These goals are listed
   in order priority order.  The protocol meets all of these goals.

     1. Avoid binding an IP address to fully define the DHCP inter-server
   protocol.  These include:

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

      + Can client while that binding is
	currently valid for another client.  In other words, don't allo-
	cate the same IP address to two clients.

     2. Ensure that an existing client can keep its existing IP address
	binding if it can communicate with any DHCP inter-server server using this
	protocol be developed without
      modifying -- not just the behavior of server that originally offered it the relay agents
	binding.

	DISCUSSION:

DRAFT							       July 1997

	   There is a subtle but very important point here.  For exam-
	   ple, assume that there are five servers using this protocol.
	   Everything is running fine, and then the clients?

      + How do network becomes par-
	   titioned, and three servers in can communicate among themselves,
	   and the SG identify a "failed" server?

      + What are other two can communicate among themselves -- but the DHCP protocol specific
	   set of three cannot communicate with the set of two.  Each
	   set, however, can communicate with some clients.

	   In this situation, every client state records defined that can communicate with a
	   DHCP server in SCSP?

      + How does SCSP support either set should be able to continue to use
	   its existing binding, even if the synchronization of pre-configured (or
      provisioned) database information?

      + What server that originally cre-
	   ated the binding is not included in the nature set of the server-to-server connection?

      + What topologies will be supported?

   We discuss each of these separately below.  Within each of the
   appendices, servers with
	   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 it can communicate.

     3. Do not add any requirement for communication with another server
	to the redundant servers within processing between a SG employ?

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

   Two distinct models are Peer Behavior DHCPDISCOVER and Primary/Secondary Behavior.
   These two models are more fully developed in Sections 3 a DHCPOFFER or
	between a DHCPREQUEST and 4
   respectively.

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

   the LS know that the DCS DHCPACK.

	DISCUSSION:

	   This is disconnected from the client pool
   associated with their SG?  Does the fact another subtle point.  The implications of this goal
	   are that the LS "lazy" update of IP address binding information is disconnected
   from
	   required.  In other words, because of this goal, the DCS yet connected protocol
	   cannot require one server to update another server with
	   information concerning a new IP address binding prior to
	   sending the client pool indicate that the DCS
   is necessarily disconnected from the client pool?  I.e., does routing
   transitivity hold?

2.2.3 Can DHCPACK to the DHCP inter-server protocol be developed without modifying
   the behavior client.

	As a result of the relay agents and the clients?

   In particular, when this goal, a server fails and another server picks up its
   bindings, how does may fail immediately after
	sending the client lease extensions, lease releases,etc.
   get DHCPACK to the new server?  Does the relay agent replicate the messages client but prior to all servers in a Server Group?  How do the servers within successfully
	sending a single
   Server Group respond record of that information to any other server.
	Should this happen, the DHCP client requests, discovery, extension,
   release?

   In [3] there is the only operational
	machine with a discussion record of a Relay Agent caching an association
   between a client this binding -- and a server for the duration of the lease protocol must
	be (and has been) designed to help
   provide properly deal with this situation.

     3. Ensure that a new client can get an IP address from some load sharing capabilities. server.

     4. If this a server goes down, and an external agent determines that it
	is in fact
   implemented, then the Relay Agent would have actually down as opposed to move this running but simply unable to com-
	municate with other servers, then the
   backup server addresses that it cur-
	rently owns but are not yet bound may be recovered for use by
	other servers.

     5. Ensure that in the event face of partition, where servers continue to
	run but cannot communicate with each other, the client server failed.

2.2.4 What above goals and
	requirements are met.  In addition, when the DHCP protocol specific client state records defined
   in SCSP?

   The SCSP defines a generic message set and semantics and associated
   client state records. partition condition
	is removed, allow graceful automatic re-integration without
	requiring human intervention.

DRAFT							       July 1997

2.3.  Limitations of this Protocol

   The specifics following are explicit limitations of the DHCP bindings must be
   mapped into this message set and client records.  Specifically, it protocol.  This is
   required not
   to define the DHCP protocol specific CSAS and CSA records
   which say that they are part not useful capabilities to have (that's why they
   are explicitly listed, so that it will be clear that this protocol
   does not supply them).

     1. Determination of the CA and CSU messages, respectively.  Loosely,
   the CSA record within a DHCP implementation is the client binding and
   the CSAS is permanent server failure.

	The protocol provides a summary message and pointer way to propagate information about the CSA on the
   originating server.

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

   The Client State Advertisement (and Summary) records are explicitly
   defined a server, but no way to support client requested bindings (or summaries).  But detect a permanent
	failure.  Transient failures are detected, but there is information provisioned into DHCP servers which must be
   distributed no mech-
	anism in this protocol to determine when a new replica server.  How this information transient failure is
   replicated needs definition within the DHCP inter-server protocol

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

   through
	really a permanent failure.  Some external agent must make this
	determination -- and must ensure that the exchange of SCSP messages.

2.2.6 What server declared perma-
	nently failed is not simply partitioned from the nature other servers
	and unable to communicate with them.  The server which has been
	declared permanently failed by the external agent MUST be
	informed of that declaration prior to restart.

	DISCUSSION:

	   The existing configuration messages allow one server to
	   declare another server as permanently failed and remove it
	   from the server-to-server connection?

   SCSP was developed within group.  That is not the ION working group and relies on an
   underlying layer two connection existing. issue.  What makes fully
	   automatic determination of permanent server failure impracti-
	   cal is the nature distinguishing between permanent server failure (which
	   is easily defined as  transient server failure that has gone
	   on too long) and partition of the
   corresponding connection for group of servers.

	   Once communication fails with a server, the DHCP server-to-server case?  Is other servers
	   cannot know if it
   none, i.e., simple UDP/IP connectivity?  (Are the acknowledgment is still operating or not, and
   timeout procedures within SCSP robust enough to run over UDP?)  Or removing an
	   operating server from the group is
   it a TCP connection?  (Need to define an activity fraught with
	   peril.

	   This protocol is designed so that a TCP port number or dynamic
   assignment server which is parti-
	   tioned from the group will re-integrate cleanly when it can
	   communicate again with the rest of the port for this protocol group.

	   Group membership protocols typically handle a partition situ-
	   ation (when they bother to run over.)

2.2.7 What topologies will be supported?

   The SCSP supports both point-to-multipoint and point-to-point
   connections between handle it at all) by having the LS
	   partitioned server determine that it has been partitioned and the DCS.
	   shut itself down.  It also supports full mesh
   and detects a partial mesh interconnection of servers within an SG.  What
   impact on the system performance will these different topologies
   have?

   Each partition condition in one of
	   two ways:  either it can't communicate with the above issues must be addressed for "master", or
	   it can't communicate with the DHCP inter-server
   protocol independent "majority" of use the generic capabilities offered by SCSP.
   The value of the SCSP is that group.  In
	   either case, it provides the lower level connection
   maintenance, database synchronization and asynchronous database
   update capabilities shuts down.

	   We believe 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 this is
   greatly simplified.  This simplification would allow the working
   group not an appropriate response for a

DRAFT							       July 1997

	   DHCP server.  If my DHCP client can talk to focus on resolving the a DHCP inter-server protocol specific
   issues identified above, server, I
	   want my client to continue to operate -- I'm not interested
	   in 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 only DHCP server to the initial
   DHCPREQUESTs which I can talk shut
	   itself down!

     2. Some addresses are temporarily unavailable during transient
	server failure.

	The full range of the clients, each existing IP addresses that are potentially
	available for allocation is reduced during the owner of their particular
   bindings, etc.  They all are capable period of randomly servicing clients
   from a tran-
	sient server failure.  The size of the pool and all of addresses that
	are responsible to propagate the binding
   information within the SG.  This model has available for allocation but not yet allocated SHOULD be
	configurable for each server.  If the advantages that it
   provides load balancing and server is subsequently
	declared to have undergone a graceful fault recovery (once defined).
   It has the disadvantages permanent failure, these addresses
	will be made available again.

	Note that it is harder to ensure non-duplicate
   address assignments and only the client bindings are distributed
   potentially making fault isolation more difficult.

3.1 PRSM Description

DRAFT         Analysis of SCSP addresses not yet allocated but avail-
	able 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 allocation that are roughly equivalent to one
   another.  Any of the servers can handle unusable during the DHCP client period of a
	transient server
   interactions.  The servers within the SG maintain sufficient TCP
   connectivity failure.  IP addresses 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 been allocated
	to all servers in the
   SG.

   The approach proposed for the PRSM, which we believe is conceptually
   the easiest clients may continue to develop, is that 1) unallocated addresses belong be used by those clients even during
	server failure.  Indeed -- to allow existing clients to
   different servers (however, they can be redistributed through able
	to renew their existing IP addresses even if the
   Address Redistribution Procedure), and 2) once a binding is made, and
   for server who
	granted them the duration lease has failed is a primary reason why this
	protocol exists.

2.4.  Failures

   This section makes explicit both classes of that binding, it 'belongs' failures as well as a
   list of specific failure scenarios in order to that server (unless facilitate discussion
   of the capabilities of this protocol.

     o "transient server dies or failure"

       A transient server failure is one where a server is unable to
       respond to requests, but later becomes disconnected for operational and able to
       respond to requests.  Its local stable storage (i.e., whatever
       mechanism it uses to preserve its set binding information) is accu-
       rate as of clients).
   States in which the bound client unicasts back to time that transient server are
   handled sufficiently well with this approach.  (Note: There are
   probably failure scenarios began.

     o "permanent server failure"

       A permanent server failure is one 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 is unable to be
   thought through in some detail.)  Client states where the bound
   client broadcast back
       respond to requests -- probably for an extended period. While the SG are handed somewhat differently.  In
       protocol defined in this case, only the owner document supports declaration of the binding should respond if a change
   to per-
       manent server failure, the binding is requested, e.g., decision that a lease extension.  If transient server fail-
       ure is in reality a change to
   the binding permanent server failure is not required, e.g., the client is in beyond the INIT-REBOOT-
   state and is only verifying an existing binding, then any scope
       of this protocol.

DRAFT							       July 1997

       This determination will be likely be performed by some adminis-
       trative entity, although in the
   servers may respond.

   When future 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 group membership proto-
       col could be a simple list
   administered into the definition of the SG which defines which server
   is to pick up integrated with the bindings belonging protocol defined in this docu-
       ment to make such determinations automatically.

     o "partition"

       A network partition is caused by a failure of the dead (or disconnected)
   server.  (We suspect underlying com-
       munications substrate, such that this new two systems that could previ-
       ously communicate cannot now do so.  This may mimic transient
       server should change the and
   should propagate these new CSA records to failure, but is not the other servers same because in the
   SG.)  Therefore, this model relies on case the notion of
       server
   'ownership' that appears to have failed may still be operational and
       interacting with clients.

       There is a form of partition known as "partial partition", where
       the client binding.  The ownership transitivity of communication usually expected is communicated
   through the

   Prior to committing any change to a client binding, e.g., sending not
       achieved.  Imagine a
   DHCPACK, set of servers organized (for the LS must purposes
       of exposition only) as a ring where each server can communicate this information
       with at least one
   DCS in its neighbors, but nobody else -- and when the SG. number of
       servers is greater than three, a partial partition situation
       exists.

       This term may cause excessive delay also be used as a noun, as in "each partition may
       communicate with ...", and in servicing DHCP
   client requests.  However, this is necessary case it refers to guarantee that no
   duplicate address assignments occur.  The advantage the group of requiring
   forwarding to only one backup server is
       servers which can communicate normally (as distinguished from
       those with which that this scales well as group cannot communicate).

     o "communication failure"

       Communications failure describes the
   number of condition where the communi-
       cation channel between two 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 becomes impossible.  "Partial
       communication failure" describes the case where the normally
       bidirectional communications channel becomes unidirectional,
       where one server can send to two, but wait for the

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

   acknowledgment not receive from only one.  Therefore, if you are running this
   protocol over noisy facilities, this would improve the probability another server.

   Some examples of
   getting the forwarding out to at least one other above failures are given below:

     1. A single server the first
   time.

   When crashes and reboots. [transient failure]

     2. A single server crashes and stays down for a period of hours and
	then reboots (either automatically or through some external
	agent).  [transient failure]

     3. A single server boots fails and establishes connectivity to the other never returns.  No permanent failure
	is declared for this server.  [transient failure]

     4. A single server fails. A permanent failure is declared for this
	server. [permanent failure]

DRAFT							       July 1997

     5. A group of two servers
   in the SG or re-establishes connectivity are partitioned so that they cannot com-
	municate, but each can communicate to other some clients.  [partition]

     6. A group of five servers in are partitioned so that three can commu-
	nicate together and the SG,
   it synchronizes its cache according to remaining two can also communicate, but
	the cache alignment protocol
   as describe in [2].

   When two partitions cannot communicate.	Each partition can com-
	municate with a server looses connectivity to another server, it should check
   to see if it is picking up subset of the ownership clients, and these subsets are
	disjoint.  [partition]

     7. A group of five servers are partitioned so that three can commu-
	nicate together and the dead server.  If so,
   it should appropriately modify remaining two can also communicate, but
	the CSA records associated two partitions cannot communicate.	Each server continues to
	be able to communicate with all of the
   dead server.  It should then force clients.  [partition]

	DISCUSSION:

	   This situation is unlikely to occur, but the SCSP cache alignment process
   with each of its remaining DCS prior protocol should
	   be able to servicing any further client
   messages.  (Note: we're assuming there a mechanism handle it.

     8. Server A can send packets to force the cache
   alignment process?)

   The available address pool is distributed over the peer servers server B, but cannot receive pack-
	ets from server B. [partial communications failure]

     9. There are four servers, A, B, C, and D.  A cannot communicate
	with C, B cannot communicate with D. [partial partition]

   DISCUSSION:

      This section on failures may well not belong in the server group.  Each unallocated address 'belongs' to a specific
   server.  The Address Redistribution Procedure distributes unallocated
   addresses to final docu-
      ment.  For the peer servers.  If a server runs low purposes of unallocated
   addresses it can request additional unallocated addresses through the
   Address Redistribution Procedure.  If it is out review of unallocated
   addresses, it must obtain more before it can make DHCPOFFERS.  This
   effectively decouples the servicing rest of clients from the request for
   unallocated addresses and should provide better performance protocol,
      however, defining a common language to describe failures and
   scaling.

   In the event giv-
      ing specific examples of a server failure, failures as an aid to discussion seemed
      useful.

3.  Overview

   At the unallocated addresses
   associated with most basic level, the failed server must be available to another server
   or DHCP protocol specifies the behavior of
   DHCP servers which communicate with DHCP clients in the SG.  These addresses are passed order to allocate
   IP address to another server
   in the server group along with clients as well as provide a variety of configura-
   tion parameters information to them.  It is the bindings which belonged allocation of IP
   addresses to clients by the
   failed server according to that creates a rule requirement to
   update what is known as discussed above.  Unallocated
   addresses are redistributed by the Address Redistribution Procedure "stable storage"  -- typically held on a need be basis.  The Address Redistribution Procedure disk.
   This information is TBD.

3.2 Protocol actions

   There are several DHCP protocol interactions that can change used to "remember" the IP address assignment information managed bindings that
   have been made by the DHCP servers:

      + New server in order to avoid allocating the
   same IP address assignment

      + Lease extension

      + Lease expiration

DRAFT         Analysis of SCSP to two clients.

   The key motivation for DHCP Redundant Servers    15 Mar 1997

      + RELEASE

   In the remainder of this section, each case an inter-server protocol 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 desire to
   allow 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 to continue to use its IP address (i.e., be able to a DHCP client (as part
   of

DRAFT							       July 1997

   renew its lease on an INIT-state transaction), IP address) even if the server adds that assignment to who initially
   offered it the lease on its
   local database of bindings.  The server must use an IP address that is available unavailable for assignment from its local some rea-
   son.  In addition, no IP address pool and must
   inform at least one of the other should ever be bound to two clients
   simultaneously.

   Providing multiple DHCP servers about to which each client can communicate
   is the newly created
   binding first step in creating this reliable DHCP capability.

   In addition, these DHCP servers must communicate among themselves in
   order to provide this reliable DHCP capability.

3.1.  Information Communicated by completing the transmission Protocol

   There are three types of a CSU message containing
   the CSA record to the other server or servers. These actions information which must be
   completed just prior to sending communicated
   between servers implementing the DHCPACK.  The SCSP server server protocol.

     o Client Binding Information

       This entire interserver protocol
   requires the DCS(s) exists in order to forward this CSU throughout the remainder allow servers
       to share information about client bindings of
   the SG.  (Note:  Specify the options/type/priority fields in the CSA
   message.)

   To identify an IP address addresses.
       Servers must be able to update other servers about client bind-
       ings that may they have created, and must be assigned able to the new client, the
   server picks an address receive similar
       updates from its local pool of assignable addresses
   (as described in the Address Redistribution Procedure) other servers about client bindings 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 other
       servers have made or changed.

     o Address
   Reassignment Procedure (soon after servicing the immediate client
   request) in Management Information

       In order to obtain implement an effective strategy for client binding
       information updates, this protocol defines some additional address.  If no addresses are
   available states
       for local assignment, no DHCPOFFER can be sent an IP address beyond those defined or implied by RFC 2131 [1]
       that are not directly connected with client binding information.
       The servers need to communicate among themselves concerning these
       states, and this communication is enabled by the
   client.

3.2.2 Lease Renewal

   A DHCP server may choose to extend address manage-
       ment information portion of the lease protocol.

     o Group Management Information

       While it is possible to conceive of a DHCP client in
   response group of servers statically
       configured to be part of a DHCPREQUEST message from a client in INIT-REBOOT-state.
   This server must be group, the 'owner' operational charac-
       teristics of the client binding.  This lease
   extension is propagated by the extending such an approach are far from pleasant.  The group
       management portion of this protocol allows a server to at least one other determine
       the groups to which another server by successfully transmitting a CSU message containing belongs; determine for each
       group the CSA
   record with current membership in the lease extension.  This must happen prior to group; determine for each
       group the subnets and IP addresses managed by that group; and
       join or leave a server transmitting the DHCPACK group.

DRAFT							       July 1997

3.2.  Server Groups

   Fundamental to the client.  The SCSP this protocol
   ensures is the propagation "group" of this information to all servers in which are com-
   municating and with which the SG.

      DISCUSSION:

      The details of this propagation require a little care clients can communicate in their

DRAFT         Analysis of SCSP for order to
   provide a reliable DHCP Redundant Servers    15 Mar 1997

      design.  The delay between lease extension and distribution service.

   Each server group (SG) to
      other servers leaves a window in which some servers may have
      different lease expiration times for a server belongs is associated with a
   particular binding.  During
      that window, set of address pools.  These address pools are those which
   exist on a client may reboot and get an old lease expiration
      date or single network segment (sometimes called a single "wire").

   An active server may determine that can be (and typically would be) a lease has expired (based on
      an old lease expiration date) after it has been extended on
      another server.

      If member of several
   groups simultaneously.  This protocol allows a client receives an old expiration date (that has not been
      extended), the client will reset its expiration date server to that old
      value.  If the lease join an
   existing SG.  Which SGs a server would join is sufficiently close to expiring, a configuration issue
   for a particular server, and outside of the client
      will use DHCP realm of this protocol --
   although considerable support is provided in order to extend the lease.  Even if make this extension takes
      place on a different server, the servers
   solvable problem.

   The membership of a particular SG will eventually converge
      to agree on the expiration time last issued change over time, and in order
   to the client.

      A server may determine ensure that a lease has expired prior to
      notification each server is made aware of any changes in group mem-
   bership in a timely way, every protocol message which is sent in the extension
   inter-server protocol includes a group generation number (with a few
   exceptions).

   Whenever a message is received, the group management layer of the
   software MUST verify that lease.  If the server takes
      no explicit action other than to delete group generation number matches the expired binding from
      its database,
   current group generation number for that SG stored in the extended lease server.  If
   there is a mismatch, the group management layer will propagate to discard the server from mes-
   sage.  It will then attempt to update its knowledge of the extending server.  The following section describes lease
      expiration current
   group (and incidentally bring its generation number up to date in more detail.

      It is hoped that the
   process).

   In this issue can be resolved by employing way, any changes in group membership become spread throughout
   the
      notion group as fast as possible -- and no messages that are out of binding ownership, e.g., lease extensions should not
      happen without explicit communication syn-
   chronization with the server currently
      owning the CSA record.  The details need to latest concept of group membership can be worked out and
      changes
   received.

   A server attempts to this section made.

3.2.3 Lease Expiration

   When become a DHCP server determines that the lease on member of a binding has
   expired, particular group by using
   the configuration messages described in Section 7 below.  In addi-
   tion, a server can remove another server simply drops that binding from its database and
   takes no other explicit action.  The address the group using these
   messages -- but in this case an external agent must ensure that binding the
   server being removed is
   available to be allocated to another client at this time truly inactive and not just partitioned.

3.3.  Messages and Operations Defined by the
   server owning Protocol

   The protocol requires that unallocated address.

      DISCUSSION:

      If a server takes no other specific action than to delete servers who implement it can communicate,
   each with the
      binding from its database, premature expiration (expiration based
      on other, in a stale expiration date) will have no effect.  The extending
      server will distribute the information about point-to-point manner (when all are operat-
   ing correctly).  It allows for the lease extension possibility that they can fail

DRAFT							       July 1997

   entirely (i.e., crash) or be unable to the communicate with each other servers, synchronizing all
   for a variety of the reasons.

   Each server will periodically need to communicate with other servers to
   in the new expiration date.

      The only potential problem arising from premature expiration is
      reassignment group.  There are several recurring styles of an address that is still communication
   that, if defined, will assist in use.  The notion that
      a server owns explaining the client binding and the associated address should

DRAFT         Analysis major concepts of SCSP
   this protocol.  These major styles of group communication are as fol-
   lows:

   There are "messages", which for DHCP Redundant Servers    15 Mar 1997

      eliminate the possibility purpose of this situations from occurring.

3.2.4 Lease RELEASE

   When a DHCP server receives a DHCPRELEASE from specification
   consist of a client and the
   server is communication between two servers.  Messages are gath-
   ered into higher level generic "operations", which describe the owner form
   of that client binding, the server should expire
   that binding operation, and transmit a CSU message containing the CSA record are made up of
   the release notification to at least messages communicated between
   more than one server.  These generic operations are then instantiated
   into specific operations as part of the other servers in the
   SG.  The other servers discard the binding record from their
   databases upon receipt various portions of the CSA record containing the DHCPRELEASE
   notification.

   If the RELEASEing server discovers any other server that has
   responded pro-
   tocol.

3.3.1.	Generic Protocol Messages

   Messages are used to communicate between a DHCPREQUEST message from the DHCP client for the
   RELEASEd address after the RELEASE message was received, the client pair of servers.

     o QUERY

       A QUERY operation is still using the address and performed when one server wishes to obtain
       knowledge about the lease server cache of another server.

     o UPDATE

       An UPDATE operation is still valid.  In this
   case, the performed when one server that has responded wishes to update
       the DHCPREQUEST message
   retains information in the ownership cache of the binding and distributes that binding to
   at least another server.

3.3.2.	Generic Protocol Operations

   These generic protocol operations are used when a server must commu-
   nicate with more than one of the other servers.

      DISCUSSION:

      The case discussed in the second paragraph server.

     o POLL

       A POLL operation is actually a DHCP
      protocol error on the part of used when one server must contact every other
       server in the client; after issuing group using a
      DHCPRELEASE, the client MUST go QUERY message in order to INIT-state and request a new
      address.  However, as there is no mechanism in DHCP through which
       that they respond with some information (typically concerning an
       IP address).  Usually, if the server can inform executing the client POLL cannot
       contact all of such an error, the other servers
      must accommodate using the error and maintain QUERY message, it will
       use whatever information it could glean from those it could con-
       tact.

     o COMPLETE POLL

DRAFT							       July 1997

       A COMPLETE POLL is like a POLL in that one server attempts to
       contact every other server using a QUERY message -- but in a COM-
       PLETE POLL it must successfully complete a QUERY with each of
       them or the consistency operation itself fails to complete.

     o PUSH

       A PUSH operation is used when one server wants to update all of
       the
      binding database. other servers using an UPDATE message.  In a way similar to
       the event that POLL operation, a PUSH operation will succeed if the original server
       employing it has died prior managed to receiving contact at least one other server in
       the group with a RELEASE message from successful UPDATE.

     o COMPLETE PUSH

       A COMPLETE PUSH is analogous to a COMPLETE POLL -- the client, COMPLETE
       PUSH operation requires the RELEASE message will not be
      propagated server to attempt to UPDATE every
       other server in the remaining servers. This is due group.  If every server responds successfully
       to the fact that UPDATE, the RELEASEing client unicasts COMPLETE PUSH succeeds, otherwise the message COMPLETE
       PUSH fails.

   Note that both PUSH and POLL involve operations to the dead server.
      The implications all of this need to be fully determined.  Currently,
      no actions are defined to try to 'capture' the client RELEASE by
      another server servers
   in the SG.

3.3 Address Redistribution Procedure

   This procedure is TBD.

   Several requirements imposed on this procedure group.

3.3.3.	Specific Protocol Operations

   These above generic forms of inter-server communication are identified utilized
   in the
   above PRSM.  These include:

      + The redistribution procedure must be capable of distributing following ways in the
      unallocated addresses at SG initialization or when initializing Client Binding and Address Management.

   Client Binding Management:

     o CLIENT BINDING POLL (operation)

       This operation involves one server asking every other server
       using a

DRAFT         Analysis of SCSP QUERY for DHCP Redundant Servers    15 Mar 1997

      new server client binding information concerning a partic-
       ular IP address.  If all of the SG.

      + The redistribution procedure should fairly distribute
      unallocated addresses.

      DISCUSSION:

      The Address Redistribution Procedure has other servers are not been fully thought
      out.  However, the procedure may be as simple as opera-
       tional, the following
      algorithm.  A requesting server which realizes that will use any information 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
       receives.

     o CLIENT BINDING COMPLETE PUSH (operation)

       This operation involves one server then goes
      down its list informing all of DCS(s).  For each DCS, the LS sends a request for
      additional addresses.  Contained in this request other
       servers using an UPDATE about updated client binding information.
       While there is utility in reaching even one other server (in some
       cases) the number of
      unallocated addresses it currently owns, say n.  The receiving DCS
      compares this operation is not deemed to its number have succeeded unless all
       of unallocated addresses, say m.  If m
      > n, then the DCS must respond to the LS other servers were successfully updated 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 new
       information.

DRAFT							       July 1997

   Address Management:

     o UNBINDABLE COMPLETE POLL (operation)

       In this procedure until it has
      corresponded with each operation, all of its DCS(s).

      To avoid situations/conditions where addresses the other servers are sparse contacted using a
       QUERY concerning one (or more) IP addresses, and
      potential battles for addresses would occur, there probably needs they all report
       on whether that IP address(es) is UNBINDABLE or not.  This opera-
       tion fails if any server fails to be some sort of throttling mechanism respond to slow down the requests.

3.4 Open Questions for QUERY or if any
       server responds to the PRSMs

      + Are these QUERY with a negative answer (i.e., the IP
       address is not currently UNBINDABLE).  It succeeds only cases in which binding information may become
           out of date?

      + Are these solutions correct?

      + Need to fully develop procedures for DHCPDECLINE, DHCPRELEASE
      and when 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 group answer that the address is
       UNBINDABLE.

     o TRANSFER (message)

       This message is used to force it to inject the information into
         at least transfer BINDABLE IP addresses from one other
       server in to another (used when the SG just prior is partitioned and the normal
       UNBINDABLE COMPLETE POLL cannot be used to committing a
         change in a client state, e.g., make an IP address assignment, a
         lease extension, etc.  Then, force
       BINDABLE, but also when all servers of the UNBINDABLE IP addresses have
       already been made BINDABLE by some server).

       The information is sent from the initiating to go into the responding
       server as a

DRAFT         Analysis QUERY and includes the subnet specification and the
       number of SCSP BINDABLE IP addresses the initiating server has avail-
       able for DHCP Redundant Servers    15 Mar 1997

         'simultaneous' cache alignment process in that address pool, and the event number of a BINDABLE IP
       addresses it is requesting.

       The responding server
         failure in the group is free to ensure that give the most recent CSA records
         are fully propagated prior to further assignments initiating server all,
       some, or extensions
         being made by none of the group.  This is to ensure non-duplicate
         address assignments.  But number of IP addresses the specifics initiating server
       has requested.

3.4.  IP Address State

   The concept of how to force a
         'simultaneous' cache alignment the state of an IP address is to be determined.

      + User intervention largely implicit in case of database incoherency
         Fixing the collective database on the
   DHCP servers RFC [1].  However, in case order to manage pools of a
         problem could IP addresses with
   multiple servers, the states and transitions between them must be a *real* nightmare.

      +
   made quite explicit.

3.4.1.	IP Address State: Basic DHCP server maintenance
         There is likely Protocol

   When an opportunity for the development of IP address is always controlled by a single DHCP server
         management tool that would download
   (implicit in the database information
         from all servers and check for conflicts/inconsistencies such
         as assignment definition of an DHCP in the current DHCP draft [1])
   the 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 either 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 BINDABLE state or the new prime. One mechanism to
   elect BOUND state.
   The following state diagram represents the primary server within an SG is described in Appendix C of
   [2].  Another mechanism is to simply define through states that an administrative
   rule the order of ascension.  Currently, IP address
   may occupy based on the Primary Election Process
   for current DHCP draft.	(Note that these terms
   do not appear in [1], but are terms that describe concepts that are

DRAFT							       July 1997

   implicit in the PSRSM is RFC.)

			+-----------------+
			|		  |
			|     BINDABLE	  |<--+
			|		  |   |
			+-----------------+   |
				 |	      |
				 V	      |
			+-----------------+   |
			|		  |   |
			|      BOUND	  |---+
			|		  |
			+-----------------+

      Figure 3.4.1-1: Basic DHCP IP address state transition diagram

   When an IP address transitions from BINDABLE to BOUND, that transi-
   tion must be determined.

   This model has recorded in the advantage of being conceptually simple server's stable storage prior to discuss,
   minimizes issues associated with duplicate address assignments and
   isolates the ownership
   transition being "published" to any observer outside of the bindings server.

3.4.2.	IP Address State: Extensions to a single server at any
   point in time. It has Support the disadvantages of not fully supporting load
   balancing.

4.1  PSRSM Description Interserver Protocol

   The PSRSM supports situation is more complex when multiple servers within a single SG.  Within the
   SG a single server acts as are managing the "Primary" server; all other servers
   act
   same set of IP addresses as "Secondary" servers. The Primary server required by this protocol.  Three new
   states are defined for an IP address: UNBINDABLE, POLLING, PUSHED and
   EXPIRED.

   This is responsible the state diagram for IP address state required by this pro-
   tocol:

DRAFT							       July 1997

			+-----------------+
			|		  |
			|    UNBINDABLE   |<--------+
			|		  |	    |
			+-----------------+	    |
				 |		    |
				 V		    |
			+-----------------+	    |
			|		  |	    |
			|     POLLING	  |-------->|
			|		  |	    |
			+-----------------+	    |
				 |		    |
				 V		    |
			+-----------------+	    |
			|		  |	    |
			|    BINDABLE	  |-------->|
			|		  |	    |
			+-----------------+	    |
				 |		    |
		   -----------------------------    |
				 V		    |
			+-----------------+	    |
			|		  |	    |
		    +-->|     BOUND	  |-------->|
		    |	|		  |	    |
		    |	+-----------------+	    |
		    |	   |	 |		    |
		    |	   |	 V		    |
		    |	   |  +-----------------+   |
		    |	   |  | 		|   |
		    |	   |  |     PUSHED	|-->|
		    |	   |  | 		|   |
		    |	   |  +-----------------+   |
		    |	   |	 |		    |
		    |	   V	 V		    |
		    |	+-----------------+	    |
		    |	|		  |	    |
		    +<--|    EXPIRED	  |-------->+
			|		  |
			+-----------------+

     Figure 3.4.2-1:  Extended DHCP IP address state transition diagram
		      required 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 Inter-server protocol.

DRAFT							       July 1997

   For every server cache which cooperates using this protocol, an IP address
   is in one of the event that following six states:

     o UNBINDABLE

       This state represents the primary server fails.

DRAFT         Analysis of SCSP default state for DHCP Redundant Servers    15 Mar 1997

   However, if a change every IP address.
       Explicit action must be taken to move an IP address from this
       state into the BINDABLE state.  An UNBINDABLE COMPLETE POLL must
       be performed and must complete successfully.

       Any IP address that has previously been BOUND must retain infor-
       mation concerning the server that PUSHED the binding is not required, e.g., information,
       the client to which it was bound, and the lease time for the
       binding.  This information is in used when a server is removed from
       the INIT-REBOOT-state and server group.

     o POLLING

       While an UNBINDABLE COMPLETE POLL operation is only verifying being performed,
       an existing
   binding, then any of IP address is in the secondary servers may respond as well.  The POLLING state.  This ensures that if two
       servers within the SG maintain sufficient TCP connectivity are simultaneously performing an UNBINDABLE COMPLETE POLL
       operation that involves the
   resultant graph spans the set same address that neither 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 them
       will succeed in making that address BINDABLE.

     o BINDABLE

       In this state, the SG.

   Prior IP address is available to committing be offered to any change in a
       DHCP client, and if the client binding, e.g., sending
   a DHCPACK, accepts the Primary server must communicate this change to at
   least one secondary DCS.  This offer, it may cause excessive delay in servicing
   DHCP client requests.  However, this is necessary be bound
       to guarantee that
   no duplicate client.

       An IP address assignments occur.  The advantage of requiring
   forwarding to is only one backup BINDABLE by a single server is that this scales well as the
   number of servers in at a SG grows; you do time.  A
       server must know for precisely which IP addresses it has on its
       list of BINDABLE addresses.  A server does not have to forward to all
   servers in a SG. There are know about any
       other server's list of BINDABLE addresses. (Although performance improvements possible in an
   implementation, e.g., your could forward to two, but wait for the
   acknowledgment from only one. Therefore, if you
       optimizations are running this
   protocol over noisy facilities, possible where a server may develop hints about
       this would improve information, they are not required).

       An IP address can move from the probability of
   getting BINDABLE state into the forwarding out to at least one other server BOUND
       state through the first
   time.

   Within this model, ownership normal activity of a client binding always resides with
   the Primary server.  Because the Primary DHCP protocol where a
       server is solely responsible
   for interacts with a client.	When this happens, the servicing Client
       Binding Management portion 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 protocol is used to
   limit inform
       other servers of the number change.

       A server can also transfer ownership 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 BINDABLE IP address to these client requests as well as
       another server upon request from that other server (and without
       any interaction beyond that with the primary server.

   When other server).

DRAFT							       July 1997

     o BOUND

       An address that is BOUND is associated with a server boots particular DHCP
       client, and establishes connectivity usually is in use by that client (although it may
       have abandoned the lease on that IP address).  It may be termed
       BOUND to that client.  In the other servers
   in BOUND state the SG or re-establishes connectivity information about
       the client binding has not been propagated to all of the 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 group.

     o PUSHED

       An address that is TBD (one
   such election process PUSHED is discussed associated with a client in the Appendix C of [2].)

   When same
       was as a secondary server or group of secondary servers become
   disconnected from the primary server (for whatever reason), they
   initiate BOUND address.	However, an address in the Primary Server Election Process.  The servers can be
   disconnected for many reasons, e.g., a failure PUSHED state
       indicates that all 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 in the primary server is newly elected, it should go

DRAFT         Analysis group have
       been informed of SCSP for DHCP Redundant Servers    15 Mar 1997

   through the SCSP cache alignment protocol with each existence of the remaining
   secondary servers prior binding to servicing client messages.  (Note: we're
   assuming there this client.

       When a mechanism to force the cache alignment process?)
   (Note: There are probably failure scenarios where the DHCP client unicasts
   back, e.g., sends releases a DHCPDECLINE lease on an IP address it moves
       from either the REQUESTING-state BOUND or a
   DHCPRELEASE from PUSHED state into 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 UNBINDABLE state,
       but no explicit PUSH operation is required.

       When the
   address assignment information managed lease time and any grace period implemented by DHCP servers:

      + New a server
       both expire, then an IP 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 moves into the nature of EXPIRED state.

       Note that only a binding, e.g., binding verification requests
   from server that actually completes a client in the INIT-REBOOT-state, can be serviced by any of CLIENT BINDING
       COMPLETE PUSH will place its IP address into the PUSHED state.
       The servers in the SG.

4.2.1  New Address Assignment

   Just prior to sending the DHCPACK, who receive the primary server completes CLIENT BINDING COMPLETE PUSH will
       place their IP addresses into the
   transmission of BOUND state.

       DISCUSSION:

	    Many DHCP servers implement something called a CSU message containing "grace
	    period", which is a period after the CSA record for the
   client lease on a binding
	    expires that an IP address will not be offered to at least one of another
	    DHCP client.  A lease which is in this "grace period" is
	    still BOUND or PUSHED as far as the secondary DCSs.  The SCSP inter-server protocol requires the DCS(s) to forward this CSU throughout is
	    concerned.

     o EXPIRED

       An IP address is EXPIRED when it was BOUND and the
   remainder term of the SG.  (Note:  Specify
       lease (and any implemented grace period) has run out.  It may be
       termed EXPIRED to that client.

       An EXPIRED IP address will transition to the options/type/priority
   fields in UNBINDABLE state
       when the CSA message.)

   If a newly elected Primary server receives a DHCPREQUEST with a
   'server identifier' other than its own, who shows it should as EXPIRED receives an UNBINDABLE
       COMPLETE POLL.  It will respond to this
   DHCPREQUEST. (How would this currently happen?)

4.2.2  Lease Renewal

   Just prior to sending the DHCPACK, the primary server completes UNBINDABLE COMPLETE POLL
       after making the
   transmission of a CSU message containing IP address UNBINDABLE.

DRAFT							       July 1997

       It may be moved back into the CSAS record for BOUND state by an REQUEST/INIT-
       REBOOT request from the
   renewed client binding previously bound client.

   Note that an IP address can never go from BOUND to at least one of client to
   BOUND to another client without first passing through the secondary DCSs. UNBINDABLE
   state.  The
   SCSP protocol requires line across the middle of the DCS(s) state transition diagram
   helps to forward this CSU throughout illustrate this.

   Further, note that the

DRAFT         Analysis transition from POLLING to BINDABLE requires
   the successful completion of SCSP for DHCP Redundant Servers    15 Mar 1997

   remainder an UNBINDABLE COMPLETE POLL.

3.5.  Overview of Server Operation

   This section will give a brief sketch of the SG.  (Note:  Specify of the options/type/priority
   fields in core elements of
   the CSA message.)

4.2.3  Lease Expiration

   When Client Binding Management and Address Management parts of the primary server determines that
   protocol (from the lease on a binding has
   expired, perspective of an already configured group of
   servers).  Many of the server simply drops that binding from its database possible cases are not described here, and
   takes no other explicit action.  The address in that binding may be
   assigned
   this section is not to a new client at be considered definitive. The definitive
   description of this time. When a secondary server
   determines that information is contained in Section 6 and in the lease on a binding has expired,
   case of conflicts with information found there, the server simply
   drops that binding from its database and takes no other explicit
   action.

4.2.4  Lease RELEASE

   When information in
   Section 6 will govern.

3.5.1.	DISCOVER

   Prior to the receipt of a primary DISCOVER message, each server receives a DHCPRELEASE from should have
   built up a client, the
   primary server completes the transmission list of a CSU message containing
   the CSAS record BINDABLE IP addresses -- for the released client binding two reasons.  First,
   because an UNBINDABLE COMPLETE POLL is required 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 move an IP address
   into the BOUND-state, BINDABLE state, and an UNBINDABLE COMPLETE POLL may not be
   possible due to a server which has recently
      died that need failure at any given instant.  Second, because
   even if an UNBINDABLE COMPLETE POLL was possible it would generally
   take too long to be thought through in some detail.  In this
      case, there is no mechanism currently defined for the newly
      elected primary do between a DISCOVER and an OFFER message.

   A server should offer a BINDABLE address to receive the client's RELEASE a client upon receipt of
   a DISCOVER message.

4.3  Primary Server Election Process

   The Primary Server Election Process

   There are no inter-server protocol activities required when a DIS-
   COVER is to be determined.

      DISCUSSION:

      However, this may be as simple as defining processed and an 'administrative
      rule' OFFER is returned to determine the order of succession (as discussed above in
      the case client (assuming
   of passing binding ownership in the PRSM above).  Or this
      may course that a BINDABLE address was available to be more automatic through the definition of offered).

3.5.2.	REQUEST/SELECTING

   When a client accepts an election
      process, such as that identified in offer by sending a SELECTING message, then
   the appendix of [2].

4.4  Open Questions for server updates its stable storage with the PSRSM

      + Can binding information
   and ACKs the client.  It must then perform a cache alignment process be 'simultaneously' imposed on CLIENT BINDING COMPLETE
   PUSH operation to push the binding information to all
      servers in of the SG? other

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar							       July 1997

         The philosophical approach taken in defining the actions of the
         assigning primary server is to force

   servers (to which it can communicate at that time).	There are some
   limitations on the lease time that can be offered to inject the
         information into client until
   at least one other successful CLIENT BINDING COMPLETE PUSH has succeeded
   for the offering server.  See Section 4.4.1 for additional details.

3.5.3.	REQUEST/INIT-REBOOT

   In the usual case where the server in who created the SG just prior
         to committing a change in a binding for the
   requesting client state, e.g., an IP address
         assignment, a lease extension, etc.  Then, force all servers managed to PUSH that information to
         go into a 'simultaneous' cache alignment process in the event
         of other
   servers using a primary CLIENT BINDING COMPLETE PUSH, the receiving server failure in
   will have the group to ensure that binding information for this client.  If this informa-
   tion can be verified, then ACK the
         most recent CSA records are fully propagated prior to further
         assignments or extensions being made by client -- else NAK it.

   If the group.  This is to
         ensure non-duplicate IP address assignments.  But was in the specifics of
         how EXPIRED state, then move the IP address
   to force the PUSHED state.

3.5.4.	REQUEST/RENEWING

   Upon receipt of a 'simultaneous' cache alignment RENEWAL message (which is unicast from the client
   to be
         determined.

      + Need to define the new primary server), it is expected that the 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 will have accurate
   information concerning the CSA and binding of the CSAS records specific to client.  If it does not,
   process the
   DHCP inter-server protocol. These records apply message like a REBINDING, below.  Given that the server
   has information sufficient to both extend the PRSM and lease, it should update its
   stable storage with the PSRSM lease extension, and so are presented separately in this section.

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

      + Must provide extended time.  Then it must perform a CLIENT BINDING COMPLETE
   PUSH operation to the capability for other servers with the auto-configuration updated binding informa-
   tion.

3.5.5.	REQUEST/REBINDING

   Upon receipt of a new
      server.  One ancillary use of the inter-server protocol REBINDING message (which is in
      configuring new DHCP servers. The DHCP inter-server protocol
      should allow broadcast from the
   client), the download of a server's configuration file and to
      allow addition of a new server will check to the list of DHCP servers.  A new
      server might be configured by simply giving see if 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, has any special
      configuration information (e.g., vendor class information) about
   the binding for this client.  There are several possible cases:

     1. Current information shows that this client owns the IP address.

	Extend the lease, update stable storage, ACK the client, and
	perform a CLIENT BINDING COMPLETE PUSH with the
      existing bindings. The new server could also announce itself information to
      all of
	the other existing servers.

      + A 'boot record'

     2. Current information shows that some other client is required which carries the provisioned
      portion of the DCHP server cache. BOUND to
	this IP address.

	This is a problem. Make the IP address UNAVAILABLE (see Section
	12 for details).

DRAFT							       July 1997

     3. Current information which
      contains the administrative information defining the says this IP address
      range, 'scopes', registered clients', etc.  It is assumed that UNBINDABLE.

	In this record is vendor specific (because of the different
      implementations of the case, a server configuration files) has probably created a binding and will be
      defined as such.  This boot record will satisfy the capabilities
      discussed in then
	failed to propagate the previous bullet item. (Note: information to this requires server.   Perform a lot

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

      more thought.)

      + The CSAS and
	POLL operation to see if any communicating server has any better
	information.

	If information is returned, then move to the CSA records are maximally defined at appropriate case in
	this
      point.  Because clients DHCPDISCOVERY messages can contain client
      specific requests for parameters, it list.

	If no information is necessary to embed returned, then extend the
      full set of options (committed to lease on the client in IP
	address, update stable storage, ACK the DHCPOFFER
      message) within client, and PUSH the CSA record.  If it is determined at a later
      date, that there is
	information in to the CSA records which are
      locally derivable, other servers.

3.5.6.	RELEASE

   When a release is received, if the client matches the binding infor-
   mation in the server, then this information will be removed from update stable storage with the
      definition of release,
   set the CSA records.

5.1  CSAS Records

   According IP address UNBINDABLE, and perform a CLIENT BINDING COMPLETE
   PUSH to inform other servers.

   If the semantics CLIENT BINDING COMPLETE PUSH operation fails due to inability
   of an UPDATE message to succeed to another server, do nothing.

3.5.7.	Expiration

   When a lease on an IP address expires, move the CSAS record defined in [2], lease to the
   CSAS record should maximally contain EXPIRED
   state and update stable storage with this information.  From now on,
   if some server performs an UNBINDABLE COMPLETE POLL operation to
   gather information about this IP address, make the 'CSA Sequence Number', IP address UNBIND-
   ABLE, update stable storage, and respond with the state of the
   'Search String' IP
   address as UNBINDABLE.

3.6.  When a server is down or partitioned and can't be contacted

   When a server is down or partitioned (i.e., can't be reached), then
   some aspects of the normal DHCP client processing are different.
   This section summarizes those differences:

     o Client lease times for new clients will never be greater than
       MAXIMUM_UNPUSHED_LEASE_TIME, since a CLIENT BINDING COMPLETE PUSH
       cannot succeed.

     o No UNBINDABLE COMPLETE PUSH will succeed, and thus no server 'Originator ID'.  Further, will
       be able to transition an address from the
   sequence number UNBINDABLE state into

DRAFT							       July 1997

       the BINDABLE state.  If a server runs low on addresses, it will
       have to use TRANSFER messages to acquire new addresses from other
       servers.

4.  Client Binding Management

   Client binding management is defined in the generic portion aspect of the CSAS record;
   only the search string and the originator ID are DHCP protocol
   specific.

   The format of which is con-
   cerned with communicating information about client bindings from one
   server to another.  It is the CSAS record for core of the DCHP inter-server protocol.

   The following messages and operations are used explicitly by a server
   participating in the interserver 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 when DHCP inter-server CSAS record format
   where

      CSA Seq.No - is part of client requests
   and events require it, and are used implicitly by the generic SCSP CSAS record format cache
   alignment procedure whenever a server (re)establishes communication
   with another server.

4.1.  Client Binding Messages

     o CLIENT BINDING UPDATE

       Update a single server with client binding information.	This
       operation will not complete successfully unless and until that
       server is updated with the information being sent.

     o CLIENT BINDING QUERY

       Query a single server for its client binding information.

4.2.  Client Binding Operations

   The operations defined in [2]

      type - represents for client binding management are:

     o CLIENT BINDING COMPLETE PUSH

       This operation involves one server using the type UPDATE message to
       inform all of the CSAS record, e.g. client, boot

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar 1997

      state - represent other servers about updated client binding
       information.  While there is utility in reaching even one other
       server (in some cases) the state operation is not deemed to have suc-
       ceeded unless all 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 - other servers were successfully updated
       with the new information.

     o CLIENT BINDING POLL

       This operation involves one server using the QUERY message to
       inquire of every other server about client binding information
       concerning a particular IP address (if assigned). address.  If not assigned, this
      field is all 0s.

      Server ID - of the Server ID encoded as in other servers

DRAFT							       July 1997

       are not operational, the DHCP options and BOOTP
      vendor extensions defined in [3].

      (Optional) requesting server will use any informa-
       tion it receives.

4.3.  Client ID - this field Binding Information

   When binding data is the optional Client ID
      encoded sent as in part of message concerned with client
   binding management it contains the DHCP options and BOOTP vendor extensions defined
      in [3]. If present, following information:

     o IP Address

     o Expiration [expressed as a delta seconds from the current time]

     o Client ID is

     o MAC Address [including the 'search string'.

      End option - determines hardware type]

     o Last Transaction [selected from the end of list below]

     o Last Transaction Time [expressed as a delta seconds from the CSAS record

   The CSA sequence number is cur-
       rent time]

     o Last Transaction Server [an IP address]

   Each server must maintain as part of the generic CSAS record defined in
   [2].  The remainder of binding information the CSAS record is
   "last transaction time", the client/server protocol
   specific portion of "last transaction", and the record.  The portion beginning "last trans-
   action server" associated with the
   Server ID that binding.

   The last transaction time is encoded as defined the time at which the binding changed in
   response to a request (the last transaction) from the DHCP Options and BOOTP Vendor
   Extensions client.  The
   last transaction time is returned in [3] using an address information message
   as a 'tag, length, variable' encoding scheme.

      DISCUSSION: number of seconds from "now".

   The inclusion possible last transactions are listed below.  This list is
   ordered by the precedence of the 'type' transactions and 'state' fields needs more thought.
      There is a desire to provide the capability used to dynamically
      propagate boot files between servers.  There are probably other
      ways help
   determine if a response to indicate the fact an address information message contains
   more recent information than that the CSAS records points to a 'boot
      file' versus currently held by a 'client record', but it is felt that this is the
      most straight forward. server.

   The record identified above last transaction is really meant to represent the
      format for a 'client record', not the 'boot file' record. However,
      the format one 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. following:

     o DHCPREQUEST/SELECTING

     o DHCPREQUEST/REBINDING

     o DHCPREQUEST/INIT-REBOOT

     o DHCPREQUEST/RENEWING

DRAFT							       July 1997

     o DHCPRELEASE

     o EXPIRATION

   The 'state' filed was included currently IP address state information is transmitted as a place holder.  There
      may be a need to be able to explicitly identify well, and it con-
   sists of one of the following states:

     o UNBINDABLE

     o POLLING

     o BINDABLE

     o BOUND

     o PUSHED

     o EXPIRED

4.4.  Initiating Client Binding Operations and Messages

4.4.1.	CLIENT BINDING COMPLETE PUSH

   The CLIENT BINDING COMPLETE PUSH operation is initiated whenever the
   state of a server's client record.  This field binding cache is placed here in anticipation of this
      requirement.

DRAFT         Analysis changed, typically by the
   receipt of SCSP for a DHCP Redundant Servers    15 Mar 1997 client request or expiration of a lease.

   The SCSP requires only lease time that is offered to a DHCP client must not be greater
   than the 'search string', MAXIMUM-UNPUSHED-LEASE-TIME for that SG until at least one
   CLIENT BINDING COMPLETE PUSH has succeeded for that client binding.
   Thus, as long as the sequence number
      and state of the Originator ID (here IP address is BOUND, then the Server ID).
   client should be offered the MAXIMUM-UNPUSHED-LEASE-TIME.

   The Client ID option
      was included because it lease time that is allowed sent to the other servers in the DHCP protocol and CLIENT BIND-
   ING COMPLETE PUSH is
      used as the 'search string' if lease time that the server would like to
   give to the DHCP client, and once a CLIENT BINDING COMPLETE PUSH has
   succeeded with that lease time in it (and the IP address state is included.  The default
      'search string' set
   to PUSHED), then the server is free to actually extend the chaddr plus ciaddr combination.  In client's
   lease on the
      event IP address with that lease time.

   The servers which receive the ciaddr is CLIENT BINDING COMPLETE PUSH will place
   their IP addresses into the BOUND state, not assigned to the client, this field PUSHED state.

DRAFT							       July 1997

4.4.2.	CLIENT BINDING POLL

   The CLIENT BINDING POLL is
      all 0s.

5.2  CSA Records

   The format of used when the CSA record for server has received a DHCP
   client request but believes that it has insufficient or out-of-date
   information concerning this client's binding.  Thus, 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 CLIENT BIND-
   ING POLL is an attempt to indicate gather more recent and up-to-date informa-
   tion from the last fragment of a record

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

      TTL - time to leave for a packet.  This represents SG.

     DISCUSSION:

	  Is this really necessary?  Given that SCSP will "align" the number of

DRAFT         Analysis
	  caches 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, servers at every reconnect, then what is the TTL
	  value of asking "again"?

4.4.3.	CLIENT BINDING UPDATE

   The CLIENT BINDING UPDATE is decremented by one.

      CSA Seq.No - initiated in three ways.

   It is part of initiated at the generic SCSP CSAS record format
      defined client binding management level as the under-
   lying operation in [2]

      Server Group ID - a 32-bit identification field CLIENT BINDING COMPLETE PUSH.  It is initiated
   at the client binding management level when a server realizes that uniquely
      identifies both
   the client/server protocol for which the servers
      of the SG are being synchronized, e.g., DHCP, as well server who returned information as the
      instance of that protocol.  This implies that multiple instances a result of a CLIENT BINDING
   QUERY returned information which was less up-to-date than that same protocol may be in operation at avail-
   able to the same time and
      have their servers synchronized independently of each other.

      type - represents current server.	It is initiated at the type SCSP level as
   part of the CSAS record, e.g. client, boot cache state - represent alignment process.

4.5.  Responding to Client Binding Messages

   When a server receives the state following client binding messages, it
   should respond as detailed below.  Note that operations consist of
   multiple messages at 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 initiator, but that when the lease was made
      to the client.  The specifics of this field processing incoming
   requests, only individual messages are to be determined. evident.

4.5.1.	CLIENT BINDING QUERY

   The intent of this field is proper response to allow another server (e.g., a newly
      booting server) CLIENT BINDING QUERY is to be able respond with the
   current information in the client binding cache.

4.5.2.	CLIENT BINDING UPDATE

   The proper response to a CLIENT BINDING UPDATE is to determine if the time
   information received is more current than that available in the
   server's cache.  If it is not, then respond negatively to this client's
      leave should expire (given as
   request.  If it is, then update the sum of client binding cache, ensure that

DRAFT							       July 1997

   the Lease Time Stamp changes have been written to stable storage, and respond success-
   fully.  Note that no CLIENT BINDING UPDATE should generate additional
   client binding message activity (i.e., the IP Address Lease Time below).

      Server ID - CLIENT BINDING UPDATE
   should not generate a CLIENT BINDING COMPLETE PUSH).

   When a CLIENT BINDING UPDATE is received, the Server ID encoded as in the DHCP options and BOOTP
      vendor extensions defined in [3] IP Address Lease Time - address should be
   placed into the BOUND state, not the PUSHED state.  Only the actual
   server performing the CLIENT BINDING COMPLETE PUSH will place its IP Address Lease Time encoded as in
   address into the DHCP options and BOOTP vendor extensions defined in [3]

      (Optional) Client ID - this filed PUSHED state.

5.  Address Managment

   Address management is the optional Client ID
      encoded as in aspect of the DHCP options and BOOTP vendor extensions defined
      in RFC 1533. If present, protocol concerned with man-
   aging the Client ID state of IP addresses that are not currently bound to any
   client.  It is a necessary part of the 'search string'.

      Remaining Options - any remaining options carried protocol in the original
      DHCPOFFER message order to support
   certain goals in the client encoded as in binding management part of the DHCP options and
      BOOTP vendor extensions defined in [3]

DRAFT         Analysis protocol,
   principally that of SCSP for DHCP Redundant Servers    15 Mar 1997

      End option - determines allowing a server to continue to operate even
   though it was partitioned from other servers in the end server group.

5.1.  Address Management Operations

     o UNBINDABLE COMPLETE POLL

       In this operation, all of the CSAS record

   The F-bit, Fragmentation Number, TTL, CSA sequence number other servers are contacted using a
       QUERY operation concerning one (or more) IP addresses, and Server
   Group ID they
       all report on whether that IP address(es) is UNBINDABLE or not.
       If they are part of UNBINDABLE, then the generic CSA record defined current information on that IP
       address is also reported (as in [2].  The
   remainder of a CLIENT BINDING POLL). In con-
       trast to a CLIENT BINDING POLL, this operation fails if any
       server cannot be contacted or if any server answers the CSA record is QUERY
       with a negative answer (i.e., the client/server protocol specific
   portion IP address is not currently
       UNBINDABLE).  It succeeds when all of the record.  The portion beginning with servers answer that the Server ID
       address is UNBINDABLE.

       There 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 subtle interaction required with the CSAS record format, group management
       layer of the format shown above is intended to protocol.	A successful UNBINDABLE COMPLETE POLL
       must be the client-type CSA
      record. Given inhibited in certain cases where a desire to support automatic booting of new servers
      and server has been
       removed from a server group.

       The case is question is that the intent here where a server is to support removed from a
       server group by a different server.  Immediately after this boot file exchange
      through the CSA record, hap-
       pens, all UNBINDABLE COMPLETE POLLS must fail for a period equal
       to the definition of MAXIMUM-UNPUSHED-LEASE-TIME.  After that time passes, then
       UNBINDABLE COMPLETE POLLS may operate as they normally do.

DRAFT							       July 1997

       DISCUSSION:

	  This covers the bootfile-type CSA
      record needs situation where a server gives a lease to be defined.  This will probably be vendor specific a
	  while both the client and will probably rely on server are partitioned.  Then, the fragmentation capability of
	  server goes away completely.	The client stays up, but remains
	  partitioned.	Then, the CSA
      record provided dead server is removed by another
	  server from the server group.  At this point, UNBINDABLE COM-
	  PLETE POLL operations could (except for in the SCSP [2].

5.3  Open Questions above restriction)
	  begin to complete successfully.  However, the client that was
	  given a lease while partitioned along with the CSAS server that
	  died certainly has an address, and CSA Records

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

      + Is partition is
	  removed (just after the right approach UNBINDABLE COMPLETE POLL operation
	  which declared its IP address now BINDABLE for new server boot file transfers some server),
	  there would be a very dangerous situation developing.

       The solution is to rely
      on the CSA records defined within the SCSP?

      + Is it necessary only offer leases to communicate clients of the 'state' field information in MAXIMUM-
       UNPUSHED-LEASE-TIME until the CSAS and CSA records?

      + How should information concerning their client
       binding reaches all of the Lease Time Stamp be encoded?

6. Conclusion

   To other servers in the group.  Once that
       happens, then they can be determined.

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

   The function of offered the SCSP "Hello" protocol normal lease time.

       Thus, whenever any server is removed from the group (where it
       doesn't remove itself), then there is a possibility that it may
       have offered leases to monitor clients about which no other server would
       have any record.  In this case, the status of remaining servers must wait
       the LS MAXIMUM-UNPUSHED-LEASE-TIME before being able to DCS connection. complete an
       UNBINDABLE COMPLETE POLL and reuse the BINDABLE addresses that
       the removed server was using.

5.2.  Address Management Messages

   The LS must be configured with following messages are part of the address management portion of
   the protocol.

     o TRANSFER

       This message is used to transfer BINDABLE IP addresses from one
       server to another (especially when the SG is partitioned and the
       normal UNBINDABLE COMPLETE POLL cannot be used to make an IP
       address BINDABLE, but also when all of its DCSs.  For each DCS (whether the low level

DRAFT         Analysis UNBINDABLE IP
       addresses have already been made BINDABLE by some server).

       The information sent from the initiating to the responding server
       includes the subnet specification and the number of SCSP BINDABLE IP
       addresses the initiating server has available for DHCP Redundant Servers    15 Mar that address
       pool, and the number of BINDABLE IP addresses it is requesting.

DRAFT							       July 1997

   connection

       The responding server is point-to-point free to give the initiating server all,
       some, or point-to-multipoint), none of the LS
   maintains an Hello Finite State Machine (HFSM). number of IP addresses the initiating server
       has requested.

     o UNBINDABLE QUERY

       The HFSM UNBINDABLE QUERY operation is shown the primitive query from which
       the UNBINDABLE COMPLETE POLL is constructed.  It is identical to
       the CLIENT BINDING QUERY defined above in terms of the figure below.

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

                Figure A-1  The Hello Finite State Machine

   Key:

      1: Link layer connection data
       returned, although the actions taken when it is established

      2: Transition based upon received are
       slightly different.

5.3.  Initiating Address Management Operations and Messages

     o UNBINDABLE COMPLETE POLL (operation)

       This operation is initiated when the receipt server detects that it needs
       to generate more BINDABLE IP addresses.	It will initiate this
       operation whenever the number of BINDABLE IP addresses drops
       below a Hello message (and
      whether configurable threshold.

       Prior to initiating this operation, the LS ID is found in server must change the  Rec ID portion
       state for each IP address that will be part of the message

      3: Hello Interval * Dead Factor exceeded

      4: Loss of link layer connectivity

   The LS UNBINDABLE
       COMPLETE POLL from UNBINDABLE to DCS connections are initialized into the down state.  The
   numbers in POLLING, and commit this state
       change to stable storage.

       DISCUSSION:

	  Is the figure refer commit to stable storage really necessary? Given that
	  we will abandon the actions discussed in POLL if we reboot (presumably), what is
	  the Key value of remembering that
   cause a transition we were doing it?

       For every IP address for which the UNBINDABLE COMPLETE POLL oper-
       ation fails (i.e., some server responds in such a way that indi-
       cates that the HFSM.  The Hello protocol employs poll
   messages IP address is not UNBINDABLE, or some server fails
       to monitor the status of respond at all), the LS IP address' state should be reset to DCS connections.
       UNBINDABLE.

     o TRANSFER (message)

       The
   format of TRANSFER message, which attempts to transfer some IP
       addresses from some other server to the Hello message initiating server, is shown below.

DRAFT         Analysis
       initiated whenever the number 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 BINDABLE IP addresses in an
       address pool falls below a configurable threshold.

DRAFT							       July 1997

5.4.  Responding to Address Management Messages

     o TRANSFER

       When receiving a TRANSFER message, the
   ID s responding server inspects
       its list of BINDABLE addresses for the DCS s that address pool to which the LS has received a Hello message from.  The
   LS' HFSM uses these ID s
       TRANSFER operation refers.  It will attempt to determine offer the status of initiat-
       ing server as many addresses as it requested, with the HFSM for each limitation
       that it will never give away more than half of the DCS s.  Multiple DCS ID s are present its pool of BIND-
       ABLE addresses in order to support
   point-to-multipoint connections. any one request.

     o UNBINDABLE QUERY

       The following field is responding server will respond to this query just like it
       responds to a CLIENT BINDING QUERY as far as the Polling
   Interval and information com-
       municated to the last field initiating server is a Dead Factor.  The product of concerned.

       In addition, if the
   Polling Interval and IP address mentioned in this query was in the Dead Factor determines
       EXPIRED state, prior to responding to this message, the length of time respond-
       ing server will move that IP address to the HFSM will hold open a connection without receiving a Hello
   from a peer DCS UNBINDABLE state,
       commit this change to stable storage, and transitioning then respond with
       information that indicates the HFSM for IP address in question was UNBIND-
       ABLE.

       Note that DCS an UNBINDABLE QUERY will not be generated to any server
       if at least one server in the Wait
   state.

   Issues SG is currently not able to resolve for DHCP Server-to-Server Implementation:

      + The transition be con-
       tacted, as known by the SCSP "Hello" subprotocol.  This will pre-
       vent unnecessary transitions from the Down EXPIRED to the Wait UNBINDABLE
       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 an UNBINDABLE COMPLETE POLL would not be a link level
      virtual circuit.  Possible triggers include a) the establishment
      of a TCP session between able to com-
       plete in any case.

6.  Actions in Response to DHCP Client Messages and Events

   This section defines the servers or b) actions that should be taken in the return client
   binding and address management portions of a ping
      off the distant server.

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

   The Cache Alignment protocol supports when incoming
   DHCP requests (messages) are received.

   DISCUSSION:

      There is considerable commonality in the initial sections that describe
      the various DHCP client messages below.  Once the details have
      stabilized, it should be possible to compress the explanations.

DRAFT							       July 1997

6.1.  DISCOVER

   Prior to the receipt of a DISCOVER message, each server cache
   synchronization process should have
   built of an LS with its DCSs.  This process a list of BINDABLE IP addresses -- for two reasons.  First,
   because a CLIENT BINDING COMPLETE POLL is required to get a BINDABLE
   IP address, and a CLIENT BINDING COMPLETE POLL may
   occur not be possible
   due to server failure at initial boot time any given instant.	Second, because even if
   a CLIENT BINDING COMPLETE POLL were possible, it would be unwise to
   require such an operation between a receipt of a DISCOVER message and
   the server, at reconnect time response of the
   server an OFFER to a client.

   There are several cases involved in processing a DISCOVER request,
   depending on the network, or other possible initialization or failure
   recovery scenarios.  Like state of the Hello protocol, requested IP address in the Cache Alignment
   (CA) protocol maintains DISCOVER
   request:

     o No specific IP address requested.

       Offer a Cache Alignment Finite State Machine
   (CAFSM) for each of its DCSs BINDABLE address to monitor the status of its cache
   alignment.  The figure below shows client.	Record that this address
       was offered in the CAFSM and indicates some cache memory of the triggers that would cause the state transitions server, but there is no
       need to occur.

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

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 the stable storage of the CAFSMs is coupled server with any informa-
       tion.  The IP address continues to be BINDABLE as far as the respective HFSMs in
       inter-server protocol is concerned.

     o Requested IP address is UNBINDABLE.

       If the LS.
   The CAFSM IP address is initialized UNBINDABLE, then perform a UNBINDABLE COM-
       PLETE POLL operation in the Down state.  It transitions an attempt to make the
   Master/Slave Negotiation state when IP address BIND-
       ABLE.  If the corresponding HFSM
   transitions to operation is successful, then respond as though the Bi-Directional state.  The CAFSM transitions back
       IP address were BINDABLE, below.  If the results of the attempt
       to make the Down state IP address BINDABLE resulted in the event a discovery that the corresponding HFSM
   transitions out of the Bi-Directional state.

   In
       IP address is now BOUND or PUSHED, then respond as for BOUND our
       PUSHED, below.  Otherwise (i.e., the Master/Slave state IP address is BINDABLE for
       some other server, or no an UNBINDABLE COMPLETE POLL was not pos-
       sible) then respond as above for "No specific IP address
       requested".

     o Requested IP address is BINDABLE.

       Offer the LS-DCS pair negotiate who IP address to the client.  IP address remains BINDABLE.

     o Requested IP address is BOUND or EXPIRED.

       If the IP address is BOUND or EXPIRED to be the
   master requesting client,
       then set it to BOUND and offer it to the client -- with a lease
       time of MAXIMUM-UNPUSHED-LEASE-TIME.  Otherwise (i.e., the connection during IP
       address is BOUND or EXPIRED to some other client), respond as in
       "No specific IP address requested", above.

DRAFT							       July 1997

     o Requested IP address is PUSHED.

       If the cache alignment process.  In IP address is PUSHED to the
   Cache Summary state requesting client, then offer
       it to the LS/DCS pair exchange Client State
   Advertisement Summary (CSAS) records within client -- with a normal lease time.  Otherwise (i.e.,
       the CA messages.  The
   servers use these message exchanges IP address is PUSHED to build a Client State
   Advertisement Request List (CRL). some other client), respond as in "No
       specific IP address requested", above.

6.2.  REQUEST/SELECTING

   The CRL indicates client uses a REQUEST/SELECTING to accept the portions offer of
   the respective a lease
   made by a server.  When a server caches that are out receives such a message, and where
   the server-id option reflects the IP address of alignment.  The cache
   mis-alignment (as indicated in that server, then if
   the local CRL) IP address is resolved in the
   Update Cache state where following states the servers exchange full client state
   information server should respond
   in CSA records within the CSU messages, only where mis-
   alignment occurs.  Once following way:

     o UNBINDABLE

       If the CRL IP address is resolved, the LS/DCS caches are
   aligned and the CAFSM transitions UNBINDABLE, then perform a UNBINDABLE COM-
       PLETE POLL operation in an attempt to make the Aligned state.

   The protocol further defines the high-level syntax of a generic CA
   message.  This format IP address BIND-
       ABLE.  If that operation is shown in successful, then respond as though
       the figure IP address were BINDABLE, 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  If the results of LS and DCS ID s , a Sequence Number, and an M, I, and O
   bits.  The M bit indicates the Master/Slave relationship,
       attempt to make the I bit
   indicates IP address BINDABLE resulted in a discovery
       that the Master/Slave relationship IP address is being negotiated and
   the O bit indicates more messages are to be exchanged.

   Issues to resolve now BOUND, then respond as for DHCP Server-to-Server Implementation:

DRAFT         Analysis of SCSP BOUND,
       below.  Otherwise (i.e., the IP address is BINDABLE for DHCP Redundant Servers    15 Mar 1997

      The SCSP generic message syntax and semantics are defined, but some
       other server, or no a complete POLL was not possible) NAK the detailed mappings required for
       REQUEST.

     o BINDABLE

       If the DHCP Server-to-Server
      implementation.  Messages IP address is BINDABLE and has been offered to be defined include:

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

         - Client State Advertisement (CSA) records within
       requester, then bind the Client
         State Update (CSU ) messages

      + Need IP address to define the client, 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 IP
       address BOUND, and update stable storage.  Then, ACK the CRL, client,
       and finally perform a PUSH operation of the LS has to be able binding information
       to determine, based
      upon the CSAS messages, that a particular client record is "out-
      of-date"?  The SCSP defines other servers.

     o BOUND or EXPIRED

       If the term "search string" which IP address is BOUND or EXPIRED to the
      key word used requesting client,
       then set the state to access BOUND, update the server cache, e.g., expiration time using the
       normal lease time, update stable storage, ACK the client HW
      address for with the DHCP implementation.  The CA header also contains
      a sequence number which is monotonically  increasing
       MAXIMUM-UNPUSHED-LEASE-TIME, and is
      assigned by the originating LS (e.g., perform a primary DHCP server in CLIENT BINDING COM-
       PLETE PUSH with the
      primary/secondary behavior model discussed above).  The
      determination of normal lease time.

       If the client state record's quality has IP address is BOUND or EXPIRED to be
      specified.

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

   The purpose of a different client, then
       NAK this REQUEST.

DRAFT							       July 1997

     o PUSHED

       If the Client State Update (CSU) protocol IP address is PUSHED to provide a
   capability the requesting client, set the IP
       address to constantly be PUSHED, update the server caches through
   asynchronous CSU message exchanges.  These updates are necessary
   because expiration time, update stable
       storage, and ACK the status client.  Finally, perform a CLIENT BINDING
       COMPLETE PUSH operation of the clients are in constant flux.  Unlike updated binding information to the
       other two sub-protocols, the Client State Update protocol does not
   maintain a separate finite state machine.  Instead, servers.

       Use the activity normal lease time in all of
   this protocol the above operations.

       If the IP address is tied PUSHED to some other client, then NAK the CAFSM.

   Each CSU can contain zero or more Client State Advertisement records.
       request.

6.3.  REQUEST/INIT-REBOOT

   The LS may send and receive CSUs when client uses a REQUEST/INIT-REBOOT to query the corresponding CAFSM server (as part of
   the client boot process) to determine if a "remembered" binding is
   still valid.  If the requested IP address will be in
   either one of the Aligned or fol-
   lowing states:

     o UNBINDABLE

       If the Cache Update states.  The CSU protocol
   defines both CSU requests and reply messages.  As consistent
   throughout IP address is UNBINDABLE, then perform a UNBINDABLE COM-
       PLETE POLL operation in an attempt to make the definition of IP address BIND-
       ABLE.  If the SCSP, operation is successful, then respond as though the CSU protocol supports both
   point-to-point and point-to-multipoint connections.

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

DRAFT         Analysis
       IP address were BINDABLE, below.  If the results of SCSP the attempt
       to make the IP address BINDABLE resulted in a discovery that the
       IP address is now BOUND, then respond as for DHCP Redundant Servers    15 Mar 1997

      The specific format of BOUND, below.  Oth-
       erwise (i.e., the Client State Advertisement (CSA)
      records within IP address is BINDABLE for some other server,
       or a complete POLL was not possible) NAK the CSU messages need to be defined REQUEST.

       DISCUSSION:

	  This means that if a server creates a binding for a client and
	  fails to PUSH 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 information to any other server prior to
	  undergoing a server failure, 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 if the client is powered off
	  prior to the NTP RFC?)

Security Considerations

   Not currently addressed - but needed.

Acknowledgments

   Many of time when it will issue a REBINDING message, it
	  will not get back the ideas same lease when it is powered back on.
	  The reasoning for this (and the difference from the REBINDING
	  case below) is that in this proposal are due to Jeff Mogul, Greg
   Minshall, Rob Stevens, Walt Wimer, Ted Lemon, John Carlson, Phil
   West, Joel Halpern and case the DHC working group.  additional
   discussions. Thanks server has no way to all who have contributed their ideas and
   participated
	  determine if the requested address in the discussion of INIT-REBOOT request
	  is current or perhaps very old indeed.  In 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

DRAFT         Analysis of SCSP for DHCP Redundant Servers    15 Mar REBINDING case
	  the client is currently using the address, so the client at
	  least believes that it is current and not in use by some other
	  client.  In this case, however, no such assumption is possi-
	  ble.

DRAFT							       July 1997

       In the case where a server which creates a binding fails prior to
       PUSHing the information about a lease to some other server, and
       the client which receives that binding makes a REBINDING request
       prior to either failing or being shutdown, it will get back the
       existing binding upon restart and INIT-REBOOT -- since the
       REBINDING will have caused a recovery of the binding information
       and that will have been distributed through a CLIENT BINDING COM-
       PLETE PUSH.

     o BINDABLE

       If the IP address is BINDABLE, then bind the IP address to the
       client, set the IP address BOUND, and update stable storage.
       Then, ACK the client, and finally perform a PUSH operation of the
       binding information to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client,
       then set the state to BOUND, update the expiration time using the
       normal lease time, update stable storage, ACK the client with the
       MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
       PLETE PUSH with the normal lease time.

       If the IP address is BOUND or EXPIRED to a different client, then
       NAK this REQUEST.

     o PUSHED

       If the IP address is PUSHED to the requesting client then set the
       IP address PUSHED, update the expiration time, update stable
       storage, and ACK the client.  Finally, perform a CLIENT BINDING
       COMPLETE PUSH operation of the updated binding information to the
       other servers.  Use the normal lease time for all of the above
       operations.

       If the IP address is PUSHED to some other client, then NAK the
       request.

6.4.  REQUEST/RENEWING

   Upon receipt of a RENEWAL message (which is unicast from the client
   to the server), it is expected that the server will have accurate
   information concerning the binding of the client since this is the
   server that the client believes most recently sent an ACK to the
   client concerning this IP address binding.

DRAFT							       July 1997

   Perform the following actions if the IP address being renewed (i.e.,
   the IP address in ciaddr) is in one of these states:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform an UNBINDABLE COM-
       PLETE POLL operation in an attempt to make the IP address BIND-
       ABLE.  If the operation is successful, then respond as though the
       IP address were BINDABLE, below.  If the results of the attempt
       to make the IP address BINDABLE resulted in a discovery that the
       IP address is now BOUND, then respond as for BOUND, below.

       If the IP address is determined to be BINDABLE for some other
       server, then NAK the request, and set the IP address to be
       UNAVAILABLE since this likely represents a duplicate allocation
       of an IP address (see Section 11, Open Questions, for details).

       Otherwise NAK the request.

     o BINDABLE

       If the IP address is BINDABLE, then bind the IP address to the
       client, set the IP address BOUND, and update stable storage.
       Then, ACK the client, and finally perform a PUSH operation of the
       binding information to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client,
       then set the state to BOUND, update the expiration time using the
       normal lease time, update stable storage, ACK the client with the
       MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
       PLETE PUSH with the normal lease time.

       If the IP address is BOUND or EXPIRED to a different client, then
       NAK this REQUEST.

     o PUSHED

       If the IP address is PUSHED to the requesting client then set the
       IP address PUSHED, update the expiration time, update stable
       storage, and ACK the client.  Finally, perform a CLIENT BINDING
       COMPLETE PUSH operation of the updated binding information to the
       other servers.  Use the normal lease time for all of the above
       operations.

       If the IP address is PUSHED to some other client, then NAK the
       request and set the IP address to UNAVAILABLE.  (see Section 11,

DRAFT							       July 1997

       Open Questions, for details).

6.5.  REQUEST/REBINDING

   Upon receipt of a REBINDING message (which is broadcast from the
   client), the server will check to the state of the address requested
   for rebinding (i.e., the ciaddr).  There are several cases possible:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform an UNBINDABLE COM-
       PLETE POLL operation in an attempt to make the IP address BIND-
       ABLE.  If the operation is successful, then respond as though the
       IP address were BINDABLE, below.  If the results of the attempt
       to make the IP address BINDABLE resulted in a discovery that the
       IP address is now BOUND, then respond as for BOUND, below.

       If the IP address is determined to be BINDABLE for some other
       server, then NAK the request.  Set the IP address to be UNAVAIL-
       ABLE since this likely represents a duplicate allocation of an IP
       address (see Section 11, Open Questions, for details).

       If no information is returned from any server that this IP
       address is anything but UNBINDABLE, then consider the address
       BOUND to this client, and proceed as in BOUND below.

       DISCUSSION:

	  This is one of the key points of the inter-server protocol.
	  In this case, a server has created a binding and then failed
	  prior to telling any other server about that binding.  Eventu-
	  ally, the client to whom that binding was made will attempt a
	  REQUEST/REBINDING and contact a different server.  That dif-
	  ferent server will be able to determine nothing about that IP
	  address.  As far as can be determined, it is not BOUND to any
	  client, and it is not BINDABLE for any other server.	In this
	  restricted case, the server will renew the lease for the
	  client and move the IP address into the BOUND state -- and
	  PUSH this information to the rest of the servers.

	  How can this be safe?  Well, remember that the client is
	  presently using the IP address to make this request.	In this
	  limited case where a server crashes before PUSHing information
	  about a BOUND IP address to any other server, the client to
	  whom the IP address is BOUND is the only running machine with
	  any record of that binding.  In this case, the DHCP servers
	  will accept that client's information about the binding as

DRAFT							       July 1997

	  correct.

     o BINDABLE

       If the IP address is BINDABLE, then bind the IP address to the
       client, set the IP address BOUND, and update stable storage.
       Then, ACK the client, and finally perform a PUSH operation of the
       binding information to the other servers.

     o BOUND or EXPIRED

       If the IP address is BOUND or EXPIRED to the requesting client,
       then set the state to BOUND, update the expiration time using the
       normal lease time, update stable storage, ACK the client with the
       MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
       PLETE PUSH with the normal lease time.

       If the IP address is BOUND or EXPIRED to a different client, then
       NAK this REQUEST.

     o PUSHED

       If the IP address is PUSHED to the requesting client then set the
       IP address PUSHED, update the expiration time, update stable
       storage, and ACK the client.  Finally, perform a CLIENT BINDING
       COMPLETE PUSH operation of the updated binding information to the
       other servers.  Use the normal lease time for all of the above
       operations.

       If the IP address is PUSHED to some other client, then NAK the
       request and set the IP address to UNAVAILABLE.  (see Section 11,
       Open Questions, for details).

6.6.  RELEASE

   When a RELEASE is received, an IP address will be in one of the fol-
   lowing states:

     o UNBINDABLE

       If the IP address is UNBINDABLE, then perform a CLIENT BINDING
       POLL operation in an attempt to determine if this IP address is
       BOUND to any client.

       If the results of the POLL operation indicate that the IP address
       is now BOUND, then respond as for BOUND, below.

DRAFT							       July 1997

       If the IP address is determined to be BINDABLE for some other
       server, then NAK the request.  Set the IP address to be UNAVAIL-
       ABLE since this likely represents a duplicate allocation of an IP
       address (see Section 11, Open Questions, for details).

       Otherwise, ignore the RELEASE.

     o BINDABLE

       If the IP address is BINDABLE, ignore the RELEASE.

     o BOUND, PUSHED, or EXPIRED

       If the IP address is BOUND, PUSHED, or EXPIRED to the requesting
       client set the IP address to be UNBINDABLE, update stable stor-
       age, and perform a CLIENT BINDING COMPLETE PUSH to update the
       other servers with this information.

6.7.  Lease Period Expiration

   When the lease period on a BOUND or PUSHED IP address expires, set
   the IP address to be EXPIRED and update stable storage.

7.  Group Management

   The group management part of the protocol is concerned with configur-
   ing a server into or out of a server group (SG).  It allows discovery
   of information concerning the configuration of an existing server
   group as well as the address pools that are managed by a server
   group.  While it is possible to conceive of a statically defined
   server group, the operational characteristics (both for group startup
   as well as removal of a server from a group) are quite painful.

   Group management messages are used add a server to a group as well as
   to remove a server from a group.  A server must add itself to a group
   -- it cannot be added by another server.  A server may be removed by
   any server in the group, including itself.

   In addition to changing the group membership, group management mes-
   sages are used to keep the various servers up to date with respect to
   the current membership of the group.

   Once a server successfully become part of a group using the group
   management messages, it the goes into the SCSP protocol.  This proto-
   col determines which servers in the SG are currently in communication
   with this server, and starts an automatch "cache alignment" process

DRAFT							       July 1997

   with each connected server.

7.1.  Group Management Operations

     o SG CHANGE

       The SG CHANGE operation is a two-stage operation made up of a
       propose and then a commit phase.  It uses the SG PROPOSE CHANGE
       and SG COMMIT CHANGE messages as part of this operation.  It is
       used to change the membership of the group, either to add a
       server or to remove a server.

7.2.  Group Management Messages

     o SG DISCOVERY QUERY

       The first stage of becoming a server participating in the inter-
       server protocol is to determine the existing SG ID for each SG
       for which participation in the inter-server protocol is desired.

       Assuming that a server has been provided or can discover the IP
       address of a server maybe in a group to which it wants to join, a
       server who wants to become a member of a group will send a SG
       DISCOVERY QUERY message to that server.

       The reply to the SG DISCOVERY QUERY message is a message which
       contains the list of SG identifiers for all of the groups to
       which the replying server belongs.  These SG ids can then be used
       in SG CONFIGURATION messages to determine more information about
       each SG.

       This operation is performed only upon one server at a time, since
       at this point there is no notion of a "current" server group.

     o SG CONFIGURATION QUERY

       The SG CONFIGURATION QUERY operation has several suboperations,
       corresponding to the following types of configuration informa-
       tion:  subnets, IP addresses, client configuration information,
       and vendor specific information.

       Each SG CONFIGURATION QUERY operation is read-only to the receiv-
       ing server.  The particular SG CONFIGURATION QUERY suboperations
       are:

DRAFT							       July 1997

       o Subnets

	 The specific subnets managed by this SG are returned in this as
	 part of this operation.

       o IP Addresses

	 The IP addresses which are managed by this SG within this sub-
	 net are return as the result of this operation.

       o Client Configuration Information

	 The client configuration information associated with this sub-
	 net is returned as the result of this operation.

       o Vendor Specific Information

	 Provision is made for vendor specific configuration information
	 to be returned in the SG CONFIGURATION message.  Its format is
	 TBD, but should be regular even though vendor specific.

     o SG PROPOSE CHANGE UPDATE

       The SG PROPOSE CHANGE UPDATE message is sent to all of the
       servers in a SG to propose a new membership in the server group.
       The information sent with this message is an updated list of the
       servers in the group.  The servers to add to the group and
       servers to remove from the group are both listed in the same mes-
       sage.

     o SG COMMIT CHANGE UPDATE

       The SG COMMIT CHANGE UPDATE message is sent to all of the servers
       in the SG to commit a change the was proposed in a SG PROPOSE
       CHANGE operation.

7.3.  Initiating Group Management Operations and Messages

7.3.1.	SG CHANGE (operation)

   The SG CHANGE operation consists of the the following steps:

     o Determine the group membership using an SG CONFIGURATION message.

       Find out to whom to send all of the SG CHANGE messages.

DRAFT							       July 1997

     o Send a SG PROPOSE CHANGE message to every member of the SG.

       This message has the current group specifier in the message,
       along with the new group membership.  As the joining server
       cycles through the existing members of the group, it will be
       rationalizing the group specifiers among the group and the entire
       group's picture of the membership of the group.	If it encounters
       a server whose view of the group membership lags behind that of
       the server from which the joining server received its idea of
       group membership, then it will bring that server up to date.

       If, on the other hand, it encounters a server that has a more up
       to date version of the group membership than the one from which
       it is operating, it will have to update its idea of the group
       membership and then start the proposal sequence over.  All of the
       servers with which it has created proposals will be forced to
       update their view of group membership as part of this process.

       At the end of this process of proposal generation, all of the
       servers in the group share a common picture of both the group
       membership as well as the current proposal.

     o Reverify the group membership from at lease one server using an
       SG CONFIGURATION message.

       This is to ensure that all of the members of the group have actu-
       ally been sent a SG PROPOSE CHANGE message.

     o Check the proposal timer.

       The initiating server must have started a timer when it sent out
       the first SG PROPOSE CHANGE message, and if that timer has less
       than time/2 time left on it, the joining server SHOULD start the
       process over.

     o Send a SG COMMIT CHANGE message to every member of the SG.

       As soon as this completes successfully with one server, the
       server has changed the membership of the group, but the initiat-
       ing server MUST continue to try to update the other servers as
       long as they remain in the server group.

7.3.2.	SG DISCOVERY QUERY (message)

   This is sent when a server wishes to know the groups to which another
   server is a member.	It is used primarily when starting up a server
   in the initial discovery of the server group configuration.

DRAFT							       July 1997

7.3.3.	SG CONFIGURATION QUERY (message)

   This message is sent to determine the details of the configuration of
   the server group.  A server would typically initiate these messages
   as part of the process of confirming that it wished to be part of a
   particular server group.

   The SG CONFIGURATION QUERY operation has several suboperations, cor-
   responding to the following types of configuration information:

     o Subnets

       The specific subnets managed by this SG are returned in this as
       part of this operation.

     o IP Addresses

       The IP addresses which are managed by this SG within this subnet
       are return as the result of this operation.

     o Client Configuration Information

       The client configuration information associated with this subnet
       is returned as the result of this operation.

     o Vendor Specific Information

       Provision is made for vendor specific configuration information
       to be returned in the SG CONFIGURATION QUERY message.  Its format
       is TBD, but should be regular even though vendor specific.

7.4.  Responding to Group Management Messages

7.4.1.	SG PROPOSE CHANGE UPDATE

   Upon receipt of a SG PROPOSE CHANGE UPDATE message, if no existing
   proposal exists that has not timed out, a server will create a single
   "proposed" group specifier from the current group specifier by incre-
   menting the group sequence number by 1.   The creation of this pro-
   posed group specifier will inhibit the creation of another proposed
   group specifier for a 30 seconds.

   If an existing proposal exists that has not timed out, the responding
   will respond negatively to the SG PROPOSE CHANGE UPDATE message.

DRAFT							       July 1997

   DISCUSSION:

      Clearly a deadlock situation can occur where two servers are try-
      ing to join a group at the same time, and each is working from
      "opposite ends" of the group.  In this case, where the joining
      server gets a failure from a SG PROPOSE CHANGE UPDATE message due
      to the existence of a valid proposal that has not timed out, then
      the joining server should backoff an amount of time that is based
      in part on its IP address before trying again.  The exact algo-
      rithm is TBD.

   This proposed group specifier will not be used in any messages until
   it moves to the accepted stage and become the current group specifier
   (see below for how it does that).

   If a second SG PROPOSE CHANGE UPDATE request is received from a
   server, that message will supersede the existing proposal and the
   timer will be reset.

   DISCUSSION

      Is there some possible attack here?  Should we limit one servers
      proposals from tying up the "proposal" for more than 3 minutes at
      a time, for instance?

7.4.2.	SG COMMIT CHANGE UPDATE

   Upon receipt of a SG COMMIT CHANGE UPDATE message, the current pro-
   posal is compared with the data in the SG COMMIT CHANGE UPDATE mes-
   sage, and if it compares successfully, the proposed new group becomes
   the current group and the group specifier is changed.

   Once a SG COMMIT CHANGE UPDATE message is received, the receiving
   server MUST examine all of its IP addresses.  For every IP address
   for which the "last transaction server" is a server which was previ-
   ously in the group and is now not in the group, the following action
   should be taken:

   If the IP address is shown as ever having been BOUND to a client, and
   if that client does not now have a different IP address, then the IP
   address should be set to BOUND to that client, the lease time should
   be restarted for the previously recorded lease time.

   DISCUSSION:

      This is a key aspect of the protocol in terms of safely removing
      possibly partitioned servers from the group.  The specific case

DRAFT							       July 1997

      that this protects against is as follows.

      If a connected server creates a client binding, and successfully
      performs a CLIENT BINDING COMPLETE PUSH operation, and then renews
      its client's lease for the full lease time -- and then becomes
      partitioned, there can be problems if that server is ultimately
      removed from the group much later.  If the server is partitioned
      for longer than the client's lease time, and if all of the other
      servers move this IP address to EXPIRED, and if then some server
      tries (unsuccessfully) to perform an UNBINDABLE COMPLETE POLL --
      which will move the EXPIRED addresses to UNBINDABLE.  Now, the
      partitioned server has updated the client several times, and the
      other servers by this time all believe that the IP address is
      UNBINDABLE.  If the partitioned server then fails and is removed
      from the SG -- the other servers could (in the absence of the
      above algorithm) believe that they only need wait the MAXIMUM-
      UNPUSHED-LEASE-TIME before then can make those UNBINDABLE
      addresses BINDABLE.  But in this case that would cause a failure.
      Thus, when a server is removed from a SG, each remaining server
      must look around for any IP addresses that it previously PUSHED,
      and set them up with their previous maximum lease time in order to
      catch this case.

7.4.3.	SG DISCOVERY QUERY

   The server groups to which the current server belongs are returned as
   the response to an SG DISCOVERY QUERY message.

7.4.4.	SG CONFIGURATION QUERY

   The SG CONFIGURATION QUERY operation has several suboperations, cor-
   responding to the following types of configuration information:

     o Subnets

       The specific subnets managed by this SG are returned in this as
       part of this operation.

     o IP Addresses

       The IP addresses which are managed by this SG within this subnet
       are return as the result of this operation.

     o Client Configuration Information

       The client configuration information associated with this subnet
       is returned as the result of this operation.

DRAFT							       July 1997

     o Vendor Specific Information

       Provision is made for vendor specific configuration information
       to be returned in the SG CONFIGURATION QUERY message.  Its format
       is TBD, but should be regular even though vendor specific.

8.  SCSP Message Mapping

   This section develops the SCSP capabilities supporting the DHCP
   interserver protocol.  The Server Cache Synchronization Protocol
   (SCSP) is found in [1].  The organization of this section is 1) we
   present a brief overview of SCSP (and refer to appendices for a more
   detailed discussion), 2) we discuss the mapping of the DHCP inter-
   server protocol onto SCSP and how the various DCHP interserver mes-
   sages are mapped into SCSP messages, 3) we identify the modifications
   to the SCSP protocol as identified in [1] necessary for the mapping
   of the DHCP interserver protocol onto SCSP, 4) we present the spe-
   cific formats of the DHCP protocol specific SCSP records and 5) we
   present a list of the open issues with respect to the mapping onto
   SCSP.

8.1.  SCSP Overview

   The Server Cache Synchronization Protocol (SCSP) is a protocol which
   provides the generic functions necessary to provide loose synchro-
   nization between a set of distributed databases.  The protocol, which
   is presented in [2], was developed to specifically address to issues
   associated with synchronizing the caches of redundant servers which
   provide the server functionality of a specific client-server proto-
   col.  SCSP was built based upon the extensive experience in develop-
   ing and running link state routing protocols such as OSPF [3].
   Client server protocols for which a redundant server capability is
   being developed using SCSP are NHRP [4] and ATM ARP [5].  Here we
   present the use of SCSP to synchronize servers supporting the DHCPv4
   client-server protocol.

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

     o The "Hello" protocol:  this protocol defines and maintains the
       status of the inter-server connection,

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

     o The "Client State Update" protocol:  this protocol provides the
       ongoing server cache synchronization through asynchronous client

DRAFT							       July 1997

       state updates.

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

   SCSP defines five message types in the operation of the above subpro-
   tocols:

     o Hello

     o Cache Alignment (CA)

     o Cache State Update (CSU) Solicit (CSU_Sol)

     o CSU Request (CSU_Req)

     o CSU Reply (CSU_Rep).

   The Hello and the CA messages are used within the Hello and the Cache
   Alignment subprotocol respectively.	The CSU_Sol, CSU_Req and CSU_Rep
   messages are used to distribute cache records between the distributed
   servers of a server group.  Full records are called Client State
   Advertisement (CSA) records.  Summary records, which are essentially
   pointers to the full records, are called Client State Advertisement
   Summary (CSAS) records.

   For a server to request a particular record, it can send a CSU_Sol
   message containing the CSAS to indicate the full record of interest.
   A server which receives a CSU_Sol is required to respond with a
   CSU_Req message containing the full CSA record associated with the
   CSAS of the CSU_Sol.  The soliciting server follows the receipt of
   the CSU_Req with a CSU_Rep to acknowledge receipt.  A server which
   wishes to communicate a full record to the rest of the SG would
   transmit a CSU_Req message containing the full CSA record.  This is
   acknowledged with a CSU_Rep message.

   DISCUSSION

      In some cases the CSU_Sol, CSU_Req, CSU_Rep sequence is overkill
      when one wants to perform a simple query operation.  See the dis-
      cussion at the end of Section 8.3 for more details.

   For now we accept that these capabilities are generically provided

DRAFT							       July 1997

   discuss the DHCPv4 interserver protocol specific overlay on SCSP.

8.2.  Mapping DHCP interserver onto SCSP

   This section presents the relationship of SCSP to the DHCP inter-
   server protocol, the assumptions made in developing this relationship
   and the specific mappings of DHCP interserver messages into SCSP.

   The assumptions made in defining the DHCP client/server protocol map-
   ping onto SCSP are the following:

     o On the Issue of Protocol Encapsulation:

       The assumption is that the SCSP messages, and in fact all inter-
       server messages, are to be defined over UDP.  Currently the SCSP
       messages within [2] are LLC/SNAP encapsulated.

     o On the Interserver over SCSP Layering Model:

       The interserver group management protocol will initialize a
       server into the group upon initial join, re-booting or re-
       connecting.  Once this is complete the interserver group manage-
       ment protocol will initialize the SCSP protocol to handle the
       ongoing operation of the interserver cache alignment and address
       management functions.

     o On the DHCP Interserver Sub-Protocols:

       The current thinking goes as follows.  The draft specification
       defines three DHCP interserver sub-protocols, i.e., the 'Client
       Binding Management' protocol (see Section 4), the 'Address Man-
       agement' protocol (see Section 5), and the 'Group Management'
       protocol (see Section 7).  The 'Client Binding Management' sub-
       protocol addresses the core of the interserver protocol in that
       it distributes and maintains the client binding records over the
       distributed SG.	This sub-protocol is to be mapped onto SCSP and
       is assigned a unique SCSP 'Protocol ID' value, e.g., the SCSP
       ProtID = 4 assigned to DCHP.  For this draft we assume that the
       Group Management sub-protocol is run on a separate UDP port from
       the SCSP UDP port.  The Group Mgmt sub-protocols will be assigned
       a unique UDP port number = tbd.	We had no compelling reason to
       carry the Address Management subprotocol on SCSP as for the
       Client Binding protocol, however for this draft we mantain both
       these sub-protocols within SCSP.  If at a later date it is deemed
       useful to separate these two protocol 1) we can define separate
       SCSP protocol types for the Cache Management and the Address Man-
       agement protocols, yet support them with a common Hello protocol
       link via the Hello protocol Family type field or 2)we can move

DRAFT							       July 1997

       the address management sub-protocol out from SCSP as in the case
       of the Group management sub-protocol.

       The mappings between the interserver messages and the SCSP mes-
       sages will cover the interserver messages handling client binding
       and address management, but not the group management protocol
       functions of the interserver protocol.  The  group management
       messages are to be defined outside of SCSP, however these mes-
       sages will follow the syntax of the SCSP message sets to simplify
       the parsing of the total message sets required within the DHCP
       interserver protocol.

       The client binding management operations are CLIENT BINDING COM-
       PLETE PUSH and CLIENT BINDING POLL.  CLIENT BINDING COMPLETE PUSH
       is required to distribute binding information and to increase the
       initial lease period to the desirable lease period.  The CLIENT
       BINDING POLL is required to solicit information on client bind-
       ings in the event that the specific server has no record of the
       client requested binding.  The Interserver messages supporting
       these operations are the CLIENT BINDING UPDATE and the CLIENT
       BINDING QUERY messages, respectively.  The SCSP records for these
       operations are 'Binding' records for the update and query mes-
       sages.

       The Address Management operations are UNBINDABLE COMPLETE POLL
       and TRANSFER.  The UNBINDABLE COMPLETE POLL initializes an
       address as bindable by the LS.  The TRANSFER allows for the
       transfer of a block of bindable addresses between servers.  The
       Interserver messages supporting these operations are the UNBIND-
       ABLE QUERY and the TRANSFER messages.  The SCSP records for these
       operations are 'Address' records for the UNBINDABLE QUERY and
       'Bindable Block Address' records for the TRANSFER messages.

       The Group Management messages are SG DISCOVERY Query, SG CONFIGU-
       RATION QUERY, SG PROPOSE CHANGE UPDATE and SG COMMIT CHANGE
       UPDATE.	The SCSP records associated with these operations are
       'SG Specifier' records for the SG DISCOVERY QUERY, 'SG Subnets'
       records for the SG CONFIGURATION QUERY, 'SG Members' records for
       the SG DISCOVERY Query, and 'SG Proposed Members' records for the
       SG PROPOSE CHANGE UPDATE and SG COMMIT CHANGE UPDATE messages.

     o On DHCP Interserver Authentication:

       The interserver protocol will rely on the authentication exten-
       sions within SCSP for the SCSP message authentication between
       servers within a server group.  The authentication of the inter-
       server group management protocol messages are tbd.

DRAFT							       July 1997

     o On the Notion of Server Ownership of Binding Records:

       It will be assumed that once the initial client binding record is
       generated by a particular server, that record will indicate that
       server as the originating server in the SCSP 'Originating Server
       ID' field.  Any further changes to that binding, whether by the
       originating server or by another server, e.g., the originating
       server is down and the client is Rebinding and getting a lease
       extension from another server, that server does change the Origi-
       nating Server ID in the SCSP record field to indicate itself as
       the last transaction server.

     o On a More Efficient Cache Alignment Process:

       The cache alignment process can be made more efficient if the
       servers time stamp their cache records.	In the event that the
       connections between servers fails, the servers determine and
       record the failure time.  Upon reconnecting and cache alignment,
       the SCSP CRL list can be limited to those records that are more
       'recent' than the failure and therefore greatly reduce the time
       and the bandwidth required.  The details are presented below.

       Also, it is not necessary to perform a cache alignment of the
       address records for the proper operation of the Interserver pro-
       tocol.  Therefore, we assume that the SCSP cache alignment pro-
       cess will not include these address records when building the
       SCSP CRL.

     o On the More Recent Record Determination:

       SCSP relies on the ability of identifying the more recent-ness of
       records when aligning and updating the cache based upon the CSA
       Sequence Number.  For binding records this implies that in situa-
       tions where it is clear that a single server is updating the
       binding, e.g., extending the lease, then it should increment the
       CSA Sequence number by one.  However there are situations in DHCP
       where multiple servers can simultaneously update the client bind-
       ing and it is not clear which of these updated bindings is
       accepted by the client, e.g., the client is in the rebinding
       state and the originating server is down and the other servers
       received the client broadcast request and the client gets multi-
       ple DHCPACKs extending the lease.  In these situations the
       servers are required to increment the CSA sequence numbers by one
       and indicate that they are the last transaction server.	Then,
       when a server caches the record, if it already has a cache record
       for that binding (as indicated by the Cache Key) it should
       replace the existing record only if the new record indicates a
       lease period which is greater than the existing record.

DRAFT							       July 1997

     o On Maximally Defined Binding Records (or the B.Hibbs' Question):

       B.Hibbs' posed the question regarding the nature of the configu-
       ration synchronization of the servers within the same SG; Does
       the DHCP Interserver protocol require synchronization of all con-
       figuration parameters or a subset? We are assuming that there is
       a minimal set of configuration and client binding information to
       be synchronized across the members of the SG to ensure the cor-
       rect operation of the DHCP Client/Server protocol.  This informa-
       tion must be carried in the interserver messages to synchronize
       the members in the SG with respect to this information.	Further,
       there may be other client binding information that the members
       want to communicate; we currently have this information encoded
       as optional in this draft.

       The parameters encoded into the 'Client Binding' records are
       those which are minimally required for the correct operation of
       the DHCP Client/Server protocol.  The interserver protocol should
       allow for situations where the configuration of the servers of
       the same server group are not strictly aligned; their configura-
       tions are only required to be aligned in the specification of the
       subnets and masks that are covered with a SG and the list of
       assignable addresses within each of the subnets.  However,
       because clients DHCPDISCOVER messages can contain client specific
       requests for parameters, it may be desirable to embed a fuller
       set of parameters (committed to the client in the DHCPOFFER mes-
       sage) within the CSA record.  This fuller set of parameters may
       be included in the initial CLIENT BINDING COMPLETE PUSH (encoded
       in the optional fields location in the record).	The server in
       receipt of a CLIENT BINDING COMPLETE PUSH may chose not to cache
       or forward these optional parameters.

     o On Knowledge Obtained Through the SCSP Hello protocol:

       The SCSP Hello protocol maintains current status of the inter-
       server connectivity through a polling mechanism.  This status
       information can be used to influence the actions of the LS, e.g.,
       in the event that the LS has lost connectivity from a DCS, then
       it should not perform a COMPLETE POLL operation.

     o On the SG Connectivity:

       It is likely that the servers of the SG are required to be fully
       interconnected, i.e., a LS is a DCS to all other servers of the
       SG.  It was first thought that this would aid in determining the
       status of the SG, i.e., whether the SG was 'up' (fully function-
       ing) or 'down' (not fully functioning).	However on further
       inspection this is not true, i.e., the loss of connectivity

DRAFT							       July 1997

       between a pair of servers in a fully connected SG does not imply
       that the other servers are not still connected to the other
       servers.  Full mesh connectivity may still be required for the
       correct operation of the Address Management protocol.  This is
       currently under study.

   When a new server wishes to join a server group, it must initialize
   itself to the other members of the server group through the above
   defined interserver Group Management Protocol.  Once this has
   occurred, the local server must initiate SCSP which then will align
   its client binding cache to that of the server group.  It should then
   acquire Bindable addresses and fully participate in the on-going
   client binding update functions of the server group.

   This process is outlined in the below state diagram for the DHCP
   interserver protocol.  The Group Management protocol handles the new
   server joining the group.  Once this has occurred, the new server and
   all the other servers of the server group initiate the SCSP Hello
   Protocol on a pairwise basis.  Per the discussion in the SCSP speci-
   fication, once bi-directional connectivity is re-verified and now
   monitored within the SCSP Hello protocol, the servers enter into the
   cache alignment and then the ongoing cache and address management
   functions.  In the event that the servers transition to the 'DOWN'
   state, polling will continue until connectivity is re-established.

   The Group Management Protocol does not allow additions to the member-
   ship in the event that the SG is down.  However it does allow for the
   removal of a server from the SG while another server is re-booting or
   disconnected.  Therefore a re-booting or re-connecting server cannot
   be assured that the SG generation has remained constant during the
   'DOWN' period.  Therefore, in the event that the generation number of
   the SG has changed as indicated through the generation number con-
   tained within the interserver messages, the server needs to update
   its notion of the server group through the procedures identified in
   the group management protocol prior to aligning its cache.

DRAFT							       July 1997

			   +------------+
			   |   Group	|
			   | Management |
			   |  Protocol	|
			   +------------+
				 |
				 |
				 V
			  +------------+
			  |    SCSP    |
			  |   Hello    |
			  +------------+
			   /	 ^   \
			  /	 |    \
			 V	 |     V
	      +--------------+	 |    +---------------+
	      |'Binding Mgmt'|	 |    |Null'Addr Mgmt'|
	      |    Cache     |---+----|     Cache     |
	      |  Alignment   |	 |    |   Alignment   |
	      +--------------+	 |    +---------------+
		     |		 |	     |
		     |		 |	     |
		     V		 |	     V
	      +--------------+	 |    +------------+
	      |'Binding Mgmt'|	 |    | 'Addr Mgmt'|
	      | Cache Update |---+----|Cache Update|
	      +--------------+	      +------------+

	      Figure 8.2-1  Interserver State Flow Diagram

   For operational efficiency, the servers should implement a scheme to
   limit the number of cache records to exchange during the cache align-
   ment process.  For example, a SG could easily be managing 10,000
   client records and the bandwidth requirements to pass even the sum-
   mary records required to build the CRL table can be quite large.
   Therefore, for the 'Cache Management' sub-protocol, the servers
   should record the times at which the cache entries were received or
   created or modified.  When the CAFSM transitions for a particular DCS
   to the down state, t(down) should be recorded.  Then when the CAFSM
   enters the cache alignment state, the CRL list is to be built up
   based upon only those records with time stamps more recent then
   t(down) - F, where F is a factor to be set to a multiple of the Hel-
   loInterval x DeadFactor.  We recommend that the multiple be 10.  In
   the event that the LS crashed (causing the transition to the down
   state), then t(down) should be set to the last record time stamp when
   the LS reboots.  In the event that the server has just joined the SG,
   the CRL should be built up from all of the current cache records.

DRAFT							       July 1997

   The interserver messages associated with the Client Binding Manage-
   ment are:  CLIENT BINDING QUERY for the CLIENT BINDING POLL opera-
   tion, and CLIENT BINDING UPDATE for the CLIENT BINDING COMPLETE PUSH
   operation.  These are discussed in detail in the following list
   items:

     o The CLIENT BINDING QUERY message queries another server regarding
       the status of a particular binding.  Within the SCSP protocol,
       this exchange is accomplished by the LS sending a Client State
       Update_Solicit (CSUS) message with the Client State Advertisement
       Summary (CSAS) 'Address record' of the IP address in question.
       The DCS responds with the CSU_Request message with the Client
       State Update (CSU) record associated with the CSAS.  The LS then
       replies with a CSU_Reply with the 'A-bit' set.

     o The CLIENT BINDING UPDATE message updates another server with a
       new, or changed, client binding.  Within the SCSP protocol, this
       exchange is accomplished with the CSU_Request message carrying
       the specific CSA 'Binding record' of the client binding in ques-
       tion.  The DCS responds with the CSA-Reply with the 'A-bit' set.

   The interserver messages associated with the Address Management are:
   UNBINDABLE QUERY for the UNBINDABLE COMPLETE POLL operation, and
   TRANSFER messages for the TRANSFER operation.  These are discussed in
   detail in the following list items:

     o The UNBINDABLE QUERY message queries another server of the SG
       regarding the status of a particular address with the intent of
       making that address bindable to the LS.	Within the SCSP proto-
       col, this exchange is accomplished by the LS sending a
       CSU_Solicit with the CSAS 'Address' record of the IP address in
       question to all other servers of the SG.  The DCSes respond with
       the CSU_Request message with the CSA 'Address' record indicating
       the status of the address within the DCS.  The LS then replies
       with the CSU_Reply message to the DCS with the 'A-bit' set.

     o The 'TRANSFER' operation is initiated by the LS to request a
       transfer of bindable addresses from the DCS to the LS.  Within
       the SCSP protocol, this exchange is accomplished by a two step
       process.  First, the LS sends a CSU_Request message with the CSA
       'Subnet Bindable Addresses' record to the DCS, which then
       responds with a CSU_Reply.  The CSA 'Subnet Bindable Addresses'
       record indicates the subnet in question, the number of BINDABLE
       addresses owned by the LS and the number of additional BINDABLE
       addresses the LS is requesting.	Second, this is immediately fol-
       lowed by the DCS sending a CSU_Request message with a CSA 'Subnet
       Bindable Address' record for the given subnet in question.  The
       DCS' CSA 'Subnet Bindable Addresses' record indicates the subnet

DRAFT							       July 1997

       in question and the number and address of the IP addresses that
       the DCS is transferring to the LS based upon it's previous
       request.  This is based upon the DCS' current understanding of
       the supply of bindable addresses within the LS and its local
       knowledge of its own set of bindable addresses for this subnet.
       This CSU_Request will generate a CSU_Reply from the originating
       LS.  When sending the CSU_Request message, the DCS sets the
       addresses it is transferring to the LS as UNBINDABLE.  The LS
       then moves these addresses to its list of BINDABLE addresses and
       sends a CSU_Reply to the DCS with the 'A-bit' set.

   The interserver messages associated with the Group Management opera-
   tions are:  SG DISCOVERY QUERY, SG CONFIGURATION QUERY, SG PROPOSE
   CHANGE UPDATE, and SG COMMIT CHANGE UPDATE messages.  These are dis-
   cussed in detail in the following list items:

     o The SG DISCOVERY QUERY message queries the DCS for its list of
       current SG in which it is participating.  Within the SCSP proto-
       col, this exchange is accomplished by the LS sending a
       CSU_Solicit with the CSAS 'Server Groups' record and the DCS
       replys with the CSU_Request message containing the CSA 'Server
       Groups' record.	This record contains the list SG specifiers,
       i.e., SG ID and SG Generation Number (GN) pairs.  The LS replies
       with a CSU_Reply.

     o The SG CONFIGURATION QUERY message queries the DCS for its con-
       figuration information.	This information is passed within the
       'SG Subnets Configuration' record.  The LS initiates this query
       by sending a CSU_Solicit containing the CSAS 'SG Subnets Configu-
       ration' summary record.	The responds with a CSU_Request contain-
       ing the CSA 'SG Subnets Configuration' record.  The LS replies
       with the CSU_Reply message.

     o The SG PROPOSE CHANGE UPDATE message proposes the new member to
       the rest of the SG.  This is accomplished with a SCSP CSU_Req
       message carrying the 'SG Proposed Members' record.  The SG COMMIT
       CHANGE UPDATE message consummates the new server joining the SG.
       Once the joining member has received positive CSU_Reply from all
       of the current members of the SG as part of the proposal phase,
       it then moves to the join commit phase.	The new server now
       issues an SCSP CSU_Req message with the 'SG Members' record car-
       rying the newly joined member to the list of servers of the SG.

     o The SG PROPOSE CHANGE UPDATE message may also be used to propose
       the removal of an existing server from the membership of the SG.
       This is accomplished with a SCSP CSU_Req message carrying the 'SG
       Proposed Members' record containing all of the existing members
       of the SG minus the server ID to be removed.  The SG COMMIT

DRAFT							       July 1997

       CHANGE UPDATE message consummates the existing server leaving the
       SG.  Once the removing member, i.e., the member who is actively
       removing the existing member from the group, has received posi-
       tive CSU_Reply from all of the current members of the SG (except
       for the member being removed) as part of the proposal phase, it
       then moves to the remove commit phase.  The removing server now
       issues an SCSP CSU_Req message with the 'SG Members' record car-
       rying the new membership minus the removed server.

8.3.  Necessary Modifications to SCSP

   The SCSP modifications required to support the DHCP interserver pro-
   tocol are as follows:

     o The operation of the SCSP protocol in this application is initi-
       ated upon the successful completion of the interserver 'Group
       Management Protocol'.

     o The SCSP messages, and in fact all of the DHCP interserver mes-
       sages are carried in UDP packets.  Therefore a UDP port number
       needs to be defined for SCSP.

       DISCUSSION:

	  Currently SCSP is defined only for NMBA networks.  This mani-
	  fests itself in two ways; a) the operation of the SCSP proto-
	  col is initiated upon the establishment of NBMA connectivity,
	  i.e., a virtual circuit being established, and b) the SCSP
	  messages are encapsulated into link level frames using the
	  LLC/SNAP encapsulation method.

	  Instead of relying upon the establishment of a virtual circuit
	  connection, the interserver protocol will initiate the SCSP
	  protocol based upon the results of the 'Group Management Pro-
	  tocol'.  This divorces the operation of the interserver proto-
	  col from the specifics of the link layer.  Also, by carrying
	  the messages within UDP, the protocol achieves independence in
	  the deployment and proximity of the servers which are members
	  of the same server group, i.e., servers are not required to
	  have an interface on a common subnet.

	  Because SCSP provides a generic capability to synchronize
	  caches in distributed servers, it is best to define a separate
	  UDP port number for the 'generic' SCSP protocol and a separate
	  UDP port for the DHCP interserver Group Management protocol.
	  These UPD port numbers are tbd.

DRAFT							       July 1997

     o A SG Generation Number SCSP extension field needs to be defined.

       DISCUSSION:

	  We have defined the notion of a Server Group Generation Number
	  to distinguish between the various instantiations of a partic-
	  ular SG.  The membership of a particular SG will change over
	  time.  Because it is necessary for the correct operation of
	  the DHCP interserver protocol for each server to know the cur-
	  rent membership, it was deemed necessary to define a Genera-
	  tion Number which is incremented each time a new server joins
	  the SG or an existing server is removed from the SG.	This GN
	  is to be carried in every interserver message.  No obvious
	  place existed with the SCSP message formats to carry such
	  information.	Therefore, we have chosen to define a new SCSP
	  extension type and will carry the GN in this method.

     o Some modification to the Authentication extension in the SCSP
       protocol may be required.

       DISCUSSION:

	  Currently SCSP states that the authentication extension covers
	  the SCSP message other than the extensions.  However we have
	  chosen to carry a new extension within the SCSP messages; the
	  Generation Number.  Ideally we would prefer that this exten-
	  sion be protected by the authentication extension.  Because it
	  is not, we will also include the Generation Number in the SG
	  Specifier record.  Through this record a server may reverify
	  the current Generation Number through a protected channel.

     o The three step Solicit_Request_Reply seems excessive when one
       server wishes to simply query another server.  Perhaps this could
       be simplified (when desirable) by adding a bit to the CSU_Solicit
       message indicating whether the soliciting server wishes the DCS
       to expect or not to expect a CSU-Rep from the soliciting server.

       DISCUSSION:

	  Currently SCSP states that the three step process of CSU_Sol
	  followed by a CSU_Req which is then followed by a CSU_Rep.  In
	  certain situations this may be a desirable sequence.	However,
	  in other situations it may not be necessary.	When the CSU_Sol
	  is sent a CSUSReXmtInterval timer is set which tracks the sta-
	  tus of the receipt of the requested CSU_Req records.	For sim-
	  ply queries, this re-transmit timer may be sufficient.  There-
	  fore, it seems reasonable that DCS should expect a CSU_Rep
	  from the LS which sent the CSU_Sol message.

DRAFT							       July 1997

8.4.  DHCP Specific CSA and CSAS Records

   This section presents the CSA and the CSAS records specific to the
   DHCP inter-server protocol.	The mappings of the interserver protocol
   onto SCSP messages discussed in the previous section relys upon the
   definition of a number of record types.  These record types will be
   distinguished within the CSAS defined 'Cache Key', which for the pur-
   pose of running the DHCP interserver protocol will consist of a
   TYPE/Key pair.  The following CSAS and CSA record types are required
   to run the interserver protocol:

   For Client Binding Management:

     o Binding Record - contains the complete client binding informa-
       tion.

   For Address Management:

     o Address Record - contains the status of a specific IP address,
       e.g., unbindable, bindable, bound, expired, etc.

     o Subnet Bindable Record - contains information regarding the sub-
       net addresses, e.g., number of bindable addresses.

   For Group Management:

     o SG Specifier Record - contains the current Server Group speci-
       fiers, i.e., the SG ID (which is fixed for the duration of the
       life of the SG) and the SG Generation Number which is incremented
       for each new server add or old server delete.

     o SG Members Record - contains the current list of member servers
       of the SG.

     o SG Subnets Configuration Record - contains a list of all subnets,
       i.e., subnet address and mask, for all of the subnets served by
       the SG as well as the assignable addresses per subnet, and poten-
       tially other configuration parameters necessary for the proper
       operation of the DHCP interserver protocol.

     o SG Proposed Members Record - contains a list of the proposed mem-
       ber servers of the SG used in the group join proposal process.
       This record has a finite duration associated with it and times
       out if the proposed join fails.

DRAFT							       July 1997

8.4.1.	The SCSP CSAS Records for the Interserver Protocol

   The CSAS record is completely specified in [2].  The format of the
   CSAS record 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	Hop Count	      |       Record Length	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cache Key Len | Orig ID Len   |N|      unused		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSA Sequence Number		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		   Cache Key	(variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     Originator ID  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		Figure 8.4.1-1	SCSP CSAS Record Format
   where:

     o Hop Count - this represents the number of hops that the record
       may take before being dropped.

     o Record Length - this is the length in bytes of the CSAS record if
       stand-alone, otherwise it is the length in bytes of the CSAS
       record and the protocol specific part of the cache entry com-
       bined, i.e., the length of the CSA record.

     o Cache Key Length - this is the length of the Cache Key field in
       bytes.

     o Originator ID Length - this is the length of the Originator ID
       field in bytes.

     o N bit -	this bit, when set, signifies a Null record.  This may
       be the case when the LS receives a solicitation for a record that
       has been released by the DHCP client.

     o CSA Sequence Number - this field contains the sequence number
       that identifies the 'newness' of a CSA record instance being sum-
       marized.  This number is assigned by the originator of the CSA
       record, i.e., the last transaction server.

DRAFT							       July 1997

     o Cache Key - is an opaque string used by the receiving server to
       identify the cache entry referred to by the record.  For the pur-
       poses of running the DHCP interserver protocol, the Cache Key
       will be encoded as a Type/Key pair, where the type is an 8 bit
       field and the length of the Key is derived from the Cache Key
       Length field in the header.  The Type indicates the type of
       record and equivalently the Interserver message type, e.g.,
       Unbindable Address Query, SG Configuration Query, etc.  The 8 bit
       type encodings are defined in the table below.

     o Originator ID - this field contains an ID which is administra-
       tively assigned to the server which is the originator of the CSA
       record.	For the DHCP interserver mapping, the the Originating
       Server ID is chosen to be the IP address of the server.	In the
       event that the server has multiple IP addresses assigned to it,
       then the Originating Server ID is set to the IP address with the
       highest value.

   The CSAS record is specified by SCSP except for the specifics of the
   Cache Key and the Originator ID.

   For the purpose of the DHCP interserver specification, the Originat-
   ing Server ID is chosen to be the IP address of the server.	In the
   event that the server has multiple IP addresses assigned to it, then
   the Originating Server ID is set to the IP address with the highest
   value.

   The Cache Key used is dependent upon the specific CSAS record in
   question.  The table below identifies the specific Cache Keys for the
   various CSAS records within the DHCP interserver protocol.  These are
   composed of a type and key field, both of which are identified in the
   table.

DRAFT							       July 1997

	Table 8.4.1-1  Cache Keys for the various CSAS and CSA records

	 Record Type	   | Encoding	   |   Key
   --------------------------------------------------
			   |		   |
   Client Binding	   |   0x00	   |  Client ID
			   |		   |  or hwaddr
   Address		   |   0x10	   |  IP addr
			   |		   |
   Subnet Bindable Addrs   |   0x11	   |  Subnet/Mask *
			   |		   |
   SG Specifiers	   |   0x20	   |  IP addr
			   |		   |
   SG Subnet Configs	   |   0x21	   |  SG ID
			   |		   |
   SG Members		   |   0x22	   |  SG ID/SG GN **
			   |		   |
   SG Proposed Members	   |   0x23	   |  SG ID/SG GN **

      * The subnet address and the subnet mask will be encoded as 32 bit
      strings with the subnet address followed by the subnet mask.

      ** The SG ID and SG GN are encoded as 16 bit strings with the SG
      ID first, immediately followed by the SG GN.

8.4.2.	The SCSP CSA Records for the Interserver Protocol

   There are several types of DHCP specific CSA records defined corre-
   sponding to each of the CSAS record types discussed above and found
   in Table 8.4.1-1.

   For many of these records, DHCP options appear in the records in the
   same format as specified in [7].

   The records are:

     o The Client Binding record carries the complete client binding
       information.  The Key for this record is the chaddr or the
       'client ID' from the optional DHCP extension.  This is utilized
       in the Cache Mgmt sub-protocol in handling the COMPLETE PUSH,
       POLL and SCSP cache alignment operations.

     o The Address record carries the information required to achieve
       the desired response from the CSU_Solicit message.  The Key is
       the IP address.	This is utilized in the Address Mgmt sub-
       protocol in handling the UNBINDABLE COMPLETE POLL operation.

DRAFT							       July 1997

     o The Subnet Bindable Address record carries the information
       required to determine the status of the available IP addresses
       which are bindable to the DCS and which it is will to transfer to
       the LS.	The Key for this record is the subnet address and mask
       of the subnet in question.  This is utilized in the Address Mgmt
       sub-protocol by the TRANSFER operation.

     o The SG Specifier record contains the total list of SG specifiers,
       i.e., SG ID and SG GN pairs, of which the server in question is
       currently a member.  This is utilized in the Group Mgmt sub-
       protocol by the DISCOVERY operation.  The Key for this record is
       the Server ID, i.e., the IP address of the server.

     o The SG Members record contains a list of the Server IDs which
       comprise the SG in question.  This is utilized in the Group Mgmt
       sub-protocol by the DISCOVER MEMBERS operation.	The Key for this
       record is the SG Specifier, i.e., the SGID and SG GN pair.

     o The SG Proposed Members record contains a list of the SG members,
       including the newly proposed member, of the server group.  This
       is utilized in the Group Mgmt sub-protocol by the PROPOSE JOIN
       operation.  The Key for this record is the SG Specifier, i.e.,
       the SGID and SG GN pair where the SG GN is one greater than the
       current GN of the SG.

8.4.2.1.  Binding Records

   The approach taken in defining the Client Binding record is as fol-
   lows.  It is possible, while still maintaining the correct operation
   of the DHCP client/server protocol, to have the different server con-
   figurations within the same server group with respect to certain
   parameters.	For these parameters we do not require synchronization
   of the server configurations and we make the passing of these parame-
   ters as optional.  However there are some configuration parameters
   and binding information which is critical to the correct operation of
   the protocol.  For these client parameters we require that they be
   included in the Client Binding records.  The minimal, required set of
   parameters to be sent in the Client Binding are the IP address
   (ciaddr), the lease period, the last transaction type, the client
   hardware address, the Client-Identifier and the Renewel (T1) and
   Rebinding (T2) Time values (if present in the DHCP options extensions
   of the DHCPACK).

   The format of the CSA Binding record for the DCHP inter-server proto-
   col is:

DRAFT							       July 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  LTT  |resrv'd|   HTYPE       |    HLEN       |    resrv'd    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		      CHADDR  (HLEN in octets)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		      CIADDR  (4 octet) 		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	       Last Transaction Time (4 octet)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     IP Address Lease Time (encoded as tag=51) (6 octet)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional ClientID (encoded as tag=61) (variable)	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional Renewal Time (encoded as tag=58) (6 octet)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional Rebinding Time (encoded as tag=59) (6 octet)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Other desirable DCHP extensions   (variable)	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   End Option (encoded as in BOOTP options, tag=255) (1 octet) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8.4.2.1-1  DHCP inter-server CSA Binding record format

   where:

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

     o LLT - indicates the Last Transaction Type.  The allowed LTTs are:
       DHCPREQUEST/SELECTING (0x0), DHCPREQUEST/REBINDING (0x3), DHCPRE-
       QUEST/RENEWING(0x2), DHCPREQUEST/INIT-REBOOT (0x1), DHCPRELEASE
       (0x4), and EXPIRATION (0x5).

     o HTYPE - hardware address type (defined in [1])

     o HLEN - hardware address length

     o CHADDR - client hardware address

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

DRAFT							       July 1997

     o Last Transaction Time - the time from now in seconds of the last
       transaction time associated with the LTT as indicated in the mes-
       sage.

     o IP Address Lease Time - the IP Address Lease Time encoded as in
       the DHCP options and BOOTP vendor extensions defined in [7].
       This represents the time from now that the client lease is to
       expire.

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

     o (Optional) Renewal Time - this field is the optional Client
       Renewal Time (T1) as encoded in the DHCP options and BOOTP vendor
       extensions defined in RFC 2132 [7].

     o (Optional) Rebinding Time - this field is the optional Client
       Rebinding Time (T2) as encoded in the DHCP options and BOOTP ven-
       dor extensions defined in RFC 2132 [7].

     o 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 [7]

     o End option - determines the end of the CSAS record

       DISCUSSION:

	  As discussed in the previous section on the CSAS record for-
	  mat, the format shown above is intended to be the Binding type
	  CSA record.  The binding record is used in the PUSH and COM-
	  PLETE PUSH operations to transfer to the DCSes the newly cre-
	  ated or changed binding and in the cache alignment procedures.
	  The structure of the Client Binding is defined, for the pro-
	  pose of the DHCP interserver protocol into a mandatory part
	  and an optional part.  The mandatory part is everything upto
	  and including the (Optional) Rebinding Time.	The optional
	  part is everything following the (Optional) Rebinding Time.
	  The PUSHing server may include any additional parameters which
	  were part of the DHCPACK message to the client within the
	  Client Binding Record and encode this as defined in the the
	  DHCP options and BOOTP vendor extensions defined in RFC 2132
	  [7].	The server which is the recipient of the PUSH may chose
	  to save and forward these optional parameters in the record or
	  may chose not to save and forward these optional parameters.

DRAFT							       July 1997

8.4.2.2.  Address Records

   The format of the CSA Address record for the DCHP inter-server proto-
   col 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  ST   | 		    reserved			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8.4.2.2-1  DHCP inter-server CSA Address record format

   where:

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

     o ST - represents the state of the (client) record, e.g., unbind-
       able, bindable, bound, expired, polling, static

       DISCUSSION:

	  The Address record is used within the UNBINDABLE COMPLETE POLL
	  operation to move an unbindable address to a bindable address.
	  The POLLed server returns the Address record indicating the
	  current status of the address within the server.  If all of
	  the servers indicate that the address is unbindable, then and
	  only then will the LS move the address to its Bindable pool.

	  The ST field indicates the servers view of the state of the
	  address.  The states (defined in Section 3.4.2) are: UNBIND-
	  ABLE, POLLING, BINDABLE, BOUND, PUSHED, and EXPIRED.

   The IP address states are encoded in the following manner:

DRAFT							       July 1997

	  Table 8.4.2.2-1  IP Address State Encodings

	   IP Address State  | Encoding
     --------------------------------------------------
			     |
     UNBINDABLE 	     |	 0x01
     POLLING		     |	 0x02
     BINDABLE		     |	 0x03
     BOUND		     |	 0x04
     PUSHED		     |	 0x05
     EXPIRED		     |	 0x06

8.4.2.3.  Subnet Bindable Addresses Record

   The CSA Subnet Bindable Addresses record indicates the set of
   addresses that a server is willing to TRANSFER to a requesting
   server.  This record is used in the TRANSFER operation.

   The format of the CSA Subnet Bindable Addresses 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | No. Addresses |No. Addr.Ranges|R|  reserved   |No.Ownd|No.Reqd|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	      List of IP Addresses			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8.4.2.3-1  DHCP inter-server CSA Subnet Bindable Addresses record
				 format

   where:

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

     o No. Address - indicates the number of IP addresses contained
       within the subnet record.  These are the addresses that the DCS
       is transferring to the LS as part of the TRANSFER operation.
       This is set to 0 when the R-bit is set to 1 (see R-bit below).

DRAFT							       July 1997

     o No. Addr. Ranges - indicates the number of IP address ranges of
       the form 135.16.114.5 to 135.16.114.235.  These will immediately
       follow the listing of the individual addresses.	This is set to 0
       when the R-bit is set to 1 (see R-bit below).

     o R - represents the request bit.	When this bit is set to 1, it
       indicates that the LS is requesting BINDABLE addresses from the
       DCS as part of the TRANSFER operation.  When it is set to 0, it
       indicates that the DCS is transferring these addresses to the LS.

     o No. Ownd - indicates the current number of BINDABLE addresses
       owned by the LS when the R-bit is set to 1.

     o No.Reqd - indicates the number of additional BINDABLE addresses
       requested by the LS when the R-bit is set to 1.

     o List of IP Addresses - this is a consecutive list of IP address
       and address ranges.

       DISCUSSION:

	  The Subnet record is used in the TRANSFER operation to indi-
	  cate 1) the list of bindable IP addresses that the DCS is
	  willing to transfer to the LS when the R bit is 0, and 2) the
	  IP addresses that the LS is requesting when the R bit is 1.

	  Further, it may be useful to develop similar records for Sub-
	  net UNBINDABLE, BOUND, PUSHED, and EXPIRED address.  They can
	  have an identical record format and be distinguished through
	  the 8 bit type field encoded into the SCSP Cache Key.  The
	  utility of these record types is TBD.

8.4.2.4.  SG Specifier Record

   The CSA SG Specifier Record indicates the total list of DHCP Inter-
   server protocol Server Groups that the DCS is currently a member.
   This is used in the Group Management subprotocol during the initial
   contact of a prospective new member to the Server Group.

   The format of the CSA SG Specifier Record for the DCHP inter-server
   protocol is:

DRAFT							       July 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |No. Specifiers | 	    reserved			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	      List of Specifier Pairs			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 8.4.2.4-1  DHCP inter-server CSA SG Specifiers record format

   where:

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

     o No. Specifiers - is a count of the number of specifier pairs con-
       tained within this CSA record.

     o List of Specifier Pairs - represents a consecutive listing of the
       specifier pairs of which the DCS is current a mamber.  The encod-
       ing of the specifier pairs is SG ID first, which is a 16 bit
       string, followed by the SG Generation Number, which is also a
       16-bit string.

       DISCUSSION:

	  This record is initially requested by a server which is inter-
	  ested in joining a DHCP Interserver Server Group and has been
	  configured with the IP address of a server to first contact.
	  The first contacted server then replies with the SG Specifier
	  record.  This record can also be solicited when a server,
	  which an existing member of a group becomes uncertain regard-
	  ing the current Generation Number of the group.

	  The SG Generation Number, obtained from this record, is car-
	  ried in every DHCP Interserver protocol message, encoded as an
	  extension to the SCSP message extension fields.  The extension
	  encoding is TBD.

8.4.2.5.  SG Subnets Configuration Record

   The CSA SG Subnet Configuration Record carries SG configuration
   information necessary to ensure the correct protocol operation of the
   group.  The encoding of this record is essentially the subnet address
   and mask followed by the pool of addresses which are dynamically

DRAFT							       July 1997

   managed by the Server Group for this subnet.  The encoding of the
   address pool with be consistent with the address pool encoding of the
   Subnet Bindable Addresses Record discussed in Section 8.4.2.3 above.
   Other configuration parameters may be including if deemed important
   to the correct operation of the DHCP interserver protocol.

   Section 7.2 specifies that additional information (specifically
   client configuration information and vendor specific configuration
   information) will be also be available.  The precise details of how
   this information is encoded is TBD.

   The format of the CSA SG Subnets Configuration 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | No. Subnets |		    reserved			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		   Subnet Address			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		   Subnet Mask				      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		   Address Pool of first subnet (variable)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		   Subnet Address			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			      ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		   Address Pool of last subnet	(variable)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8.4.2.5-1  DHCP inter-server CSA SG Subnets Configuration record
format

   where:

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

     o No. Subnets - indicates the number of subnet configurations con-
       tained in this record.

DRAFT							       July 1997

     o Subnet Address - this is the subnet address of the subnet for
       which the following address pool is related.

     o Subnet Mask - this is the mask of the subnet in question.

     o Address pool of subnet - this is a listing of the address pool
       for which this SG can allocate from for this particular subnet.
       The encoding will follow the address pool encoding for the Subnet
       Bindable Addresses record.  Therefore, the address pool should
       contain two count fields, the first indicating the number of
       individually listed addresses, followed by another field indicat-
       ing the number of address ranges.  These are then followed by the
       list of individual IP addresses and then the list of address
       ranges.

       DISCUSSION:

	  The total list of configuration items to be incorporated into
	  this record needs to be further fleshed out.	Currently this
	  record is planned to contain a list of the subnets and the
	  address pools associated with each from which this SG can
	  allocate.  If other configuration parameters are deemed neces-
	  sary for the proper operation of the DHCP Interserver proto-
	  col, then these need to be incorporated into this record.

8.4.2.6.  SG Members Record

   The CSA SG Members Record indicates the list of the current SG mem-
   bers, in the opinion of the sending server, including itself.

   The format of the CSA SG Members 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | No. Server IDs|P|	      reserved			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		    List of Server IDs			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 8.4.2.6-1  DHCP inter-server CSA SG Members record format

   where:

DRAFT							       July 1997

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

     o No. Server IDs - this is the number of Server IDs contained
       within this record.

     o P bit - the Proposal bit is used to indicate that this record is
       a current group members record (here set to 0) or a proposed
       group members record (discussed in the next section).

     o List of the Server IDs - this is a consecutive list of Server IDs
       which comprise this server's view of the current SG membership.
       The Server IDs are IP addresses associated with one of the
       server's interfaces.

8.4.2.7.  SG Proposed Members Record

   The CSA SG Proposed Members Record indicates the list of the current
   SG members, in the opinion of the sending server, and adding itself.
   This is a temporary record (with a lifetime associated with the
   period during which a Group Management SG CHANGE operation has to
   complete).  Once the SG COMMIT CHANGE UPDATE is received, this record
   replaces the old SG Members record as the new member record contain-
   ing the newly joined server.

   The format of the CSA SG Proposed Members 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     CSAS Record  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | No. Server IDs|P|	    reserved			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	      List of Server IDs			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 8.4.2.7-1  DHCP inter-server CSA SG Proposed Members format

   where:

     o CSAS Record - represents the full CSAS record as identified in
       Section 8.4.1.

DRAFT							       July 1997

     o No. Server IDs - this is the number of Server IDs contained
       within this record.

     o P bit - the Proposal bit is used to indicate that this record is
       a proposed group members record (here set to 1) or a current
       group members record (discussed in the previous section).

     o List of the Server IDs - this is a consecutive list of Server IDs
       which comprise the sending server's view of the proposed SG mem-
       bership.  The Server IDs are IP addresses associated with one of
       the server's interfaces.

       DISCUSSION:

	  This record contains the proposed group membership from the
	  view of the proposing server.  This record conceptually has a
	  temporary lifetime associated with the period for which a
	  group join proposal can live.  If a server receives a SG COM-
	  MIT CHANGE UPDATE message, then this record becomes the new SG
	  Members record.  If a SG COMMIT CHANGE UPDATE message is not
	  received within the appropriate period, then this record
	  expires.  If the server receives a second SG PROPOSE CHANGE
	  UPDATE message while another Proposed Members record is
	  active, it should NAK this second Proposed Members record.
	  Only one group join can be in process at any given time.

8.5.  Open Questions with the Mapping onto SCSP

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

     o SCSP is currently LLC/SNAP encapsulated.  We are proposing that a
       UDP port be defined to carry SCSP messages for DHCP.  In fact we
       are proposing that the entire DHCP interserver protocol be run
       over UDP.

     o SCSP has currently reserved its Protocol ID = 4 for DHCP. This
       draft discusses DHCPv4 Interserver protocol and therefore the
       SCSP Protocol ID reservation should reflect that fact.  If a
       DHCPv6 extension to this draft were developed it would require a
       separate SCSP Protocol ID.

     o SCSP dropped support for message fragmentation.	We need to look
       into the size required for the various records defined in this
       draft and, if necessary, consider how to handle records larger
       than can fit into a single UDP packet.

DRAFT							       July 1997

     o Need to give further thought to the partitioning of the DHCP
       interserver protocol into three separate but related subproto-
       cols; the Group Management, the Binding Management and the
       Address Management subprotocols.  Currently this draft has these
       as separate subprotocols, with the Group Management subprotocol
       run separate from the SCSP protocol and in fact on a different
       UDP port as the SCSP protocol.  The Group Management does however
       share common message semantics and syntax with the SCSP messages
       in order to simplify parsing the various messages associated with
       the DHCP interserver protocol.  The Binding Management and the
       Address Management subprotocols are run on top of SCSP with a
       single Protocol ID.

     o We need to explicitly discuss the method used to authenticate the
       DHCP Interserver protocol messages.  Current thinking is to use
       the SCSP authentication extensions.  This should be investigated
       and should be consistent with the 'Security Architecture for
       DHCP' draft [8].

9.  IP Address State Transitions

   The possible states of an IP address were defined in Section 3.2.2,
   and the state transition diagram appears there.  The state transi-
   tions though which an IP address can move were discussed implicitly
   in Section 6 in the context of the receipt of DHCP messages from DHCP
   clients.  However, an explicit examination of the processing required
   of a server by this protocol on each of the state transitions will
   serve to highlight some important aspects of this protocol.

   The IP address state transitions are handled in the following way:

     o UNBINDABLE -> POLLING

       When a server attempts to make a particular IP address BINDABLE,
       it first moves that IP address into the POLLING state.  Once in
       this state, if queried about whether that IP address is UNBIND-
       ABLE, the server will reply negatively.

     o UNBINDABLE -> BOUND

       When a server is removed from a server group, all of the IP
       addresses must be scanned to see if any of them show that server
       as the server who performed the last transaction (as set by that
       server successfully completing a CLIENT BINDING COMPLETE PUSH).
       For all of those IP addresses, if there is a client recorded in
       the IP address, and if that client does not have a currently dif-
       ferent binding, then that IP address must be set to BOUND and the
       lease time must be reset to the value sent in the latest CLIENT

DRAFT							       July 1997

       BINDING COMPLETE PUSH.

       The only states from which this transition will be made are
       UNBINDABLE and EXPIRED.

     o POLLING -> BINDABLE

       A fundamental point and guarantee of this state transition dia-
       gram is that for an IP address to move from the UNBINDABLE state
       (where it is not owned by any server) through the POLLING state
       and on to the BINDABLE state (where it is owned by a single
       server) requires the server seeking to own the IP address to con-
       tact all of the other servers in the group.  It requires an
       UNBINDABLE COMPLETE POLL to complete successfully.

       The server attempting to move an IP address from the UNBINDABLE
       through the POLLING and on to the BINDABLE state must ask every
       other server in the group if it believes that the IP address is
       currently UNBINDABLE using an UNBINDABLE COMPLETE POLL.	If any
       server says that the IP address is either BINDABLE (i.e., it cur-
       rently owns the IP address) or BOUND (i.e., a client currently
       owns the IP address), then the server attempting to move the IP
       address from the UNBINDABLE to BINDABLE state MUST abandon the
       attempt.  If any server fails to respond at all, the server MUST
       abandon the attempt as well.

       DISCUSSION:

	  In addition (and this is important!) if the server attempting
	  to move the IP address from the UNBINDABLE state through the
	  POLLING state and on to the BINDABLE state fails to hear from
	  some other server, then the attempt cannot complete.	This
	  means that if a server cannot communicate with every other
	  server (due to communications failure, transient server fail-
	  ure, or network partition) then this state transition cannot
	  be made.

       Thus, all addresses in the UNBINDABLE state will stay in that
       state while any server in the group is out of communication with
       the group for any reason at all.

       Of course, the detailed description of the protocol suggests that
       a server build up a supply of BINDABLE IP addresses so that in
       the event of server failure it has BINDABLE addresses that are
       available to offer to new DHCP clients.

     o BINDABLE -> BOUND

DRAFT							       July 1997

       Once an IP address is BINDABLE it may be BOUND to a client
       through the normal actions of the DHCP protocol.  Once a server
       has received a DHCPREQUEST/SELECTING message from a client it can
       move the IP address into the BOUND state, update its stable stor-
       age, and reply with a DHCPACK message to the client.

       After the DHCPACK has been sent, the DHCP server MUST also
       attempt to update all servers in the group with information indi-
       cating that the IP address is now BOUND to a particular client.
       It must perform a CLIENT BINDING COMPLETE PUSH operation with
       this information.

       An IP address that is BOUND will always result in a lease time
       that is no greater than the MAXIMUM-UNPUSHED-LEASE-TIME when
       given to a client, although the normal lease time is used in all
       interactions with other servers.

       DISCUSSION:

	  In an ideal world, the server who created the binding would
	  always succeed in updating all other servers in the group with
	  the binding information.  Then, in the event that the binding
	  server failed at some later time, another server to whom the
	  client could broadcast would receive a DHCPREQUEST/REBINDING
	  request and could reply with updated binding information.

	  However, there is obviously a window where a server can crash
	  after sending a DHCPACK and prior to updating even one addi-
	  tional server.  This protocol has been designed so that not
	  only is the process of updating all of the servers in the
	  group with information concerning a new binding "lazy" (i.e.,
	  performed after the actual binding is made), but also unneces-
	  sary for correct operation.  The protocol only requires that a
	  server try to update the other servers -- not that it succeed
	  at updating even one server.

	  The protocol accomplishes this by allowing a server to respond
	  to a DHCPREQUEST/REBINDING message from a client without any
	  information having been propagated from the server who created
	  the binding.	Thus, a server who receives a rebinding request
	  for an IP address about which it has no information must check
	  with all available servers in the group, but in the absence of
	  information to the contrary arriving within a relatively short
	  timeout period, the server should respond to the rebinding
	  request with an extension of the existing lease on the IP
	  address.

DRAFT							       July 1997

     o BINDABLE -> UNBINDABLE

       A server can relinquish an IP address in the BINDABLE state that
       it owns simply by responding to requests for information about
       the IP address as if it were UNBINDABLE.  No explicit action need
       be taken other than to respond correctly to POLL operations from
       other servers.

     o BOUND -> PUSHED

       Once an IP address that is BOUND to a client has a CLIENT BINDING
       COMPLETE PUSH succeed (and that means succeed to all of the
       servers), then it moves from the BOUND to the PUSHED state.  At
       this point, the normal lease time may be returned to the client
       on the next renewal or discover or rebinding.

       Note that only the server which executes the CLIENT BINDING COM-
       PLETE PUSH will set its IP address into the PUSHED state.  The
       state that it PUSHes to the other servers is BOUND.

     o BOUND -> UNBINDABLE

       In order for an IP address to move from the BOUND to the UNBIND-
       ABLE state, the client that owns the IP address (i.e., to which
       it is BOUND) must send a DHCPRELEASE message.  In this case, the
       receiving server (which may or may not be the server who created
       original binding) will update its stable storage with information
       that the IP address is not currently BOUND by any client.  It
       should then transmit this information to all other servers to
       which it can communicate at that time by performing a CLIENT
       BINDING COMPLETE PUSH operation.

       In the event that the server fails to update any other server
       with the new information about the IP address prior to undergoing
       some failure, then the worst that will happen is that the other
       servers will believe that an IP address is in the BOUND state
       when it need not be.  Ultimately the lease on the IP address will
       expire.

     o BOUND -> EXPIRED

       Any server which has information concerning a BOUND IP address
       may determine that the lease on the IP address has expired, and
       after an appropriate grace period has elapsed, that the IP
       address should be moved to the EXPIRED state.  A record of the
       client to which the IP address was BOUND must be kept.

DRAFT							       July 1997

     o PUSHED -> UNBINDABLE

       In order for an IP address to move from the PUSHED to the UNBIND-
       ABLE state, the client that owns the IP address (i.e., to which
       it is BOUND) must send a DHCPRELEASE message.  In this case, the
       receiving server (which may or may not be the server who created
       original binding) will update its stable storage with information
       that the IP address is not currently BOUND by any client.  It
       should then transmit this information to all other servers to
       which it can communicate at that time by performing a CLIENT
       BINDING COMPLETE PUSH operation.

       In the event that the server fails to update any other server
       with the new information about the IP address prior to undergoing
       some failure, then the worst that will happen is that the other
       servers will believe that an IP address is in the PUSHED state
       when it need not be.  Ultimately the lease on the IP address will
       expire.

     o PUSHED -> EXPIRED

       Any server which has information concerning a PUSHED IP address
       may determine that the lease on the IP address has expired, and
       after an appropriate grace period has elapsed, that the IP
       address should be moved to the EXPIRED state.  A record of the
       client to which the IP address was PUSHED must be kept.

     o EXPIRED -> UNBINDABLE

       If any server asks for information concerning this IP address,
       then the receiving server should set the IP address to be UNBIND-
       ABLE, update its stable storage, and respond to the requesting
       server.

     o EXPIRED -> BOUND

       If a server receives a message from a client and the IP address
       is EXPIRED, but was last BOUND or PUSHED to that client, then the
       IP address can be moved back into the BOUND state.  This is pos-
       sible because no other server can have attempted to make this IP
       address BINDABLE.  If it had, the IP address would not be in the
       EXPIRED state anymore, but in the UNBINDABLE state (see the
       EXPIRED -> UNBINDABLE transition above).

       Another reason this transition can occur is as follows.	When a
       server is removed from a server group, all of the IP addresses
       must be scanned to see if any of them show that server as the
       server who performed the last transaction (as set by that server

DRAFT							       July 1997

       successfully completing a CLIENT BINDING COMPLETE PUSH).  For all
       of those IP addresses, if there is a client recorded in the IP
       address, and if that client does not have a currently different
       binding, then that IP address must be set to BOUND and the lease
       time must be reset to the value sent in the latest CLIENT BINDING
       COMPLETE PUSH.

       The only states from which this transition will be made are
       UNBINDABLE and EXPIRED.

10.  Security Considerations

   Minimal security would be provided by configuring every server in a
   group with the IP addresses of the allowable servers that could ever
   join that group.

   Some additional security is created by using the SCSP security mecha-
   nism, although there are limitations to that for other than the
   client binding management part of the protocol.

   Other, more powerful security approaches are and must be addressed
   prior to further progress on this protocol.

11.  Open Questions

   The following open questions set off by the "*" character remain from
   Ralph Droms' original draft:  draft-ietf-dhc-interserver-00.txt.
   Comments have been added in square brackets [].  Additional open
   questions new to this draft are listed with the "o" character.

     * Each server must know all other servers.

       Requiring each server to know about every other server imposes
       additional administrative overhead in the configuration of DHCP
       servers.  However, this configuration overhead is probably mini-
       mal relative to any other configuration required for DHCP
       servers.

       [The group management messages in Section 7 provide a step
       towards an answer here.	A server needs to know only one other
       server.]

     * Each server must contact all other servers before reassigning an
       address.

DRAFT							       July 1997

       [This is fundamental if we wish to use the "lazy synchronization"
       mode -- you can't get one without the other.]

       There is a potential issue here in which no new DHCP clients can
       be configured if any of the DHCP servers cannot be contacted.
       Servers can mitigate this problem by maintaining a list of pre-
       checked addresses that can be allocated without contacting all
       other servers at the time of address allocation.

       The protocol may need additional definition of specific actions
       on the part of DHCP servers in response to situations in which a
       server cannot contact all other servers.  [Added a lot of these
       in this draft.]

     * Servers cooperating to achieve "fair" distribution of available
       addresses.

       The protocol may need additional mechanisms or definition of
       default behavior through which servers cooperate among themselves
       to ensure that each has a sufficient pool of prechecked-addresses
       on each network.

       [Not yet addressed, and needs work. Initial thinking is that all
       addresses should be allocated to some server, so that if the
       event of a SG where one member can't be contacted, the maximum
       addresses are available for TRANSFER operations as necessary.]

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

     * Potential deadlock in checking address - suppose two servers
       check the same address for reassignment simultaneously?

       [Solved with the introduction of the POLLING state.]

     * Potential configuration for new server?

       One ancillary use of the inter-server protocol might be in con-
       figuring new DHCP servers.  Suppose the inter-server protocol
       were extended to allow 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

DRAFT							       July 1997

       could also announce itself to all of the other existing servers.

       [Much of this is in the current draft, principally in the group
       management configuration messages.  At this stage, a server can
       figure out which groups correspond with which subnets, which
       addresses that group manages on that subnet, and some additional
       configuration information.  This is considerable distance towards
       both ensuring that all servers in the SG have compatible configu-
       rations, as well as towards one server downloading configuration
       data from another server.

       Downloading configuration files would not be a great idea for
       servers which don't use configuration files.]

     * 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 incon-
       sistent lease expiration times, etc.

     o Group-id selection.

       The group-id's for various groups need to be sufficiently unique
       that no server will ever be a member of two groups with the same
       group-id.  No mechanism is provided yet in this protocol to gen-
       erate group-id's which conform to this requirement.

       Possibly a group-id can be synthesized in some manner to ensure
       that they conform to this requirement.

     o The original draft discussed the requirement for each server to
       have a synchronized clock using available time synchronization
       protocols.  That requirement has been removed in this draft, and
       in its place all times are sent in "seconds from now" as a signed
       32 bit number.  There is clearly a bit of additional complexity
       required to do this, but we have been so impressed at how well
       DHCP works with "relative" instead of "absolute" time that we
       felt the complexity of using relative time worth it (since using
       synchronized time is not without its own complexities).

     o UNAVAILABLE IP addresses

       There are several cases where a server can determine that some
       sort of serious error has occurred, and apparently an IP address
       is in an inconsistent state.  In these cases, the server should

DRAFT							       July 1997

       make the IP address UNAVAILABLE -- i.e., no other server should
       be able to operate on it.  Just what is necessary to make this
       happen?	Could it be a passive response to address information
       messages, or must it involve a complete push to all of the other
       servers, and a new IP address state?

12.  Acknowledgments

   Many of the ideas in this proposal are due to Jeff Mogul, Greg Min-
   shall, Rob Stevens, Walt Wimer, Ted Lemon and the DHC working group.
   Thanks to all who have contributed their ideas and participated in
   the discussion of the inter-server protocol.

   At American Internet, Brad Parker and Mark Stapp have been key con-
   tributors to the design discussions that have resulted in our contri-
   butions to the this draft.  They have each invested many hours of
   work in this protocol.

13.  References

     [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	 March 1997.

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

     [3] Moy, J.  "OSPF Version 2", IETF RFC1247, July 1991.

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

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

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

     [7] Alexander, S.,  Droms, R., "DHCP Options and BOOTP Vendor
	 Extensions", Internet RFC 2132, March 1997.

     [8] Gudmundsson, Olafur, "Security Architecture for DHCP", draft-
	 ietf-dhc-security-arch-00.txt.

DRAFT							       July 1997

14.  Author's information

      Kim Kinnear
      American Internet Corporation
      4 Preston Ct.
      Bedford, MA  01730-2334

      Phone: (617) 276-4587
      EMail: kinnear@american.com

      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

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

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

DRAFT							       July 1997

Appendix A:  An Overview of SCSP

   This appendix presents an overview of the SCSP protocol and supple-
   ments Section 8.2 in the main text of this specification.  For a com-
   plete discussion of the SCSP protocol see [2].

   This appendix is divided into three following sections on the SCSP
   Hello, Cache Alignment and Cache Update subprotocols respectively.
   The last section of this appendix presents a summary of the SCSP mes-
   sage sets.

A.1 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.  The protocol contains a 'Family ID' which
   allows for the multiplexing of multiple protocol specific SCSP imple-
   mentations to rely on a single Hello mechanism between each server
   pair.  For each DCS (whether the low level 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	  |<-------+
		 |	  |		  |	   |
		 |	  +---------------+	   |
		 |	      |       ^ 	   |
		 |	      |       | 	   |
		 |	      |       | 	   |
		 |	      |       | 	   |
		 |	      V       | 	   |
		 |	  +---------------+	   |
		 |	  |		  |	   |
		 |	  |    WAITING	  |	   |
		 |     +--|		  |--+	   |
		 |     |  +---------------+  |	   |
		 |     |    ^		^    |	   |
		 |     |    |		|    |	   |
		 |     V    |		|    V	   |
	       +---------------+     +---------------+
	       |  BIDIRECTION  |---->|	UNIDIRECTION |
	       |	       |     |		     |
	       |  CONNECTION   |<----|	CONNECTION   |
	       +---------------+     +---------------+

	      Figure A.1-1  The Hello Finite State Machine

DRAFT							       July 1997

   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 (Note:  These numbers didn't appear in
   the original figure in [2], and are TBD).  The Hello protocol employs
   poll messages to monitor the status of the LS to DCS connections.

   The Hello messages 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 messages also contain two fields; the Polling Interval and the
   Dead Factor.  The product of the Polling Interval and the Dead Factor
   determines the length of time that the HFSM will hold open a connec-
   tion without receiving a Hello from a peer DCS and transitioning the
   HFSM for that DCS to the Wait state.

A.2  The SCSP "Cache Alignment" Sub-protocol

   The Cache Alignment protocol supports the initial server cache syn-
   chronization 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) proto-
   col 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.

DRAFT							       July 1997

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

	   Figure A.2-1  Cache Alignment Finite State Machine

Key:

     1: When HFSM reaches Bi-directional state

DRAFT							       July 1997

     2: HFSM transitions out of Bi-directional state

     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

   (Note: The key numbers don't appear in the figure in [2],a and are
   TBD.)

   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 transi-
   tions 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 Advertise-
   ment 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 indi-
   cated 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 transi-
   tions to the Aligned state.

   The protocol further defines the high-level syntax of a generic CA
   message as discussed in a later section of this appendix.

A.3  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 asyn-
   chronous 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 proto-
   col is tied to the CAFSM.

   Each CSU can contain zero or more Client State Advertisement records.

DRAFT							       July 1997

   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 through-
   out the definition of the SCSP, the CSU protocol supports both point-
   to-point and point-to-multipoint connections.

A.4  The SCSP Message Set Overview

   The structure of the SCSP messages is a)a fixed length, generic
   header, b) a SCSP message specific part header of variable length, c)
   an fixed length, message field and d) zero, one or more SCSP message
   specific records.  This is shown in the following figure.

       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	      |       Packet Size	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     IP Checksum 	      |    Start of Extensions	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	 SCSP Message Specific part (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol ID	      | 	  SG  ID	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       unused		      | 	 Flags		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sender ID Len | Recvr  ID Len |       No. of Records	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	       Sender ID   (variable)			      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	       Receiver ID   (variable) 		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 	SCSP Message Specific Records	(variable)	      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		   Figure A.4-1  SCSP Message Format

   where

     o Version - is the version of the SCSP protocol defined in [2]

     o type - represents the SCSP message type, i.e., CA, Hello,
       CSU_Req, CSU_Reply, and CSU_Solicit

     o Packet Size -

DRAFT							       July 1997

   The SCSP messages have identical syntax except for the 1) the SCSP
   message specific part header and 2) the SCSP message specific part
   record.  The following table summarizes the content of these specific
   parts:

		    Table A.4-1  SCSP Message Specific Parts

	       |  Hello    |   CA      |   CSUS    | CSU_Req   |  CSU_Reply
   ------------------------------------------------------------------------
	       |	   |	       |	   |	       |
   SCSP mesg   | hello int,|CSA Seq.No.|  null	   |  null     |   null
   spec header | dead fac.,|	       |	   |	       |
	       | Family ID |	       |	   |	       |
   ------------------------------------------------------------------------
	       |	   |	       |	   |	       |
   SCSP mesg   |Additional |CSAS Rec.  | CSAS Rec. | CSA  Rec. | CSAS Rec.
   spec record | Recvr ID  |	       |	   |	       |
	       | records   |	       |	   |	       |

   The detailed formats of the various SCSP messages are given in [2].
   However, two SCSP message specific records are of particular interest
   to the development of the DHCP interserver specification.  These are:
   1) the CSAS record and 2) the CSA record.  The CSAS record is defined
   within the SCSP specification as:

       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	(variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 		     Originator ID  (variable)		      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		 Figure A.4-2  SCSP CSAS Record Format

   See Section 8.4.1 for details.

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

   The CSA record is defined within the SCSP specification as:

       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 Cache Entry     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		  Figure A.4-3	SCSP CSA Record Format

   The CSA records for the DHCP interserver mapping to SCSP are defined
   in Section 8.4.2.

   [end of document <draft-ietf-dhc-interserver-02.txt>]