Network Working Group R. Droms INTERNET DRAFT Bucknell University R. Cole AT&T MNS March 1997 Expires August 1997 An Inter-server Protocol for DHCP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The DHCP protocol is designed to allow for multiple DHCP servers, so that reliability of DHCP service can be improved through the use of redundant servers. To provide redundant service, multiple DHCP servers must carry the same information about assigned IP addresses and parameters; i.e., the servers must be configured with the same bindings. Because DHCP servers may dynamically assign new addresses or configuration parameters, or extend the lease on an existing address assignment, the bindings on some servers may become out of date. The DHCP inter-server protocol provides an automatic mechanism for synchronization of the bindings stored on a set of cooperating DHCP servers. The underlying capabilities of the DHCP inter-server Droms, Cole [Page 1] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 protocol required for multiple server cache replications are based upon the Server Cache Synchronization Protocol (SCSP). 1. Introduction DHCP servers manage the assignment of IP address and configuration parameters to IP hosts. The DHCP protocol specification [1] refers to the collection of configuration information assigned to a client as a "binding". The DHCP protocol is designed to allow for multiple DHCP servers, so that reliability of DHCP service can be improved through the use of redundant servers. To provide redundant service, the distributed DHCP servers' databases must be configured with the same information about assigned IP addresses and parameters; i.e., client bindings must be replicated in multiple server databases. Because DHCP servers may dynamically assign new addresses or configuration parameters, or extend the lease on an existing address assignment, the bindings on some servers may become out of date. The DHCP inter-server protocol provides an automatic mechanism for synchronization of the bindings stored on a set of cooperating DHCP servers. Much of the underlying capabilities provided by the DHCP inter-server protocol will rely on the capabilities provided by another protocol, the Server Cache Synchronization Protocol (SCSP) [2]. The SCSP protocol defines a generic capability for the replication of multiple, dispersed, replica server databases. The SCSP places no topological requirements on the interconnection of the replica databases other than the requirement that the resultant graph spans the total set of servers. The SCSP protocol itself borrows heavily from the work of link state protocol database replication. The DHCP inter-server protocol uses TCP between pairs of servers. Each server is configured with a list of all other servers. The servers are also all configured with a pool of candidate IP addresses that may be assigned dynamically to DHCP clients. Periodically or on demand, a server may contact one, some or all other DHCP servers to perform DHCP inter-server protocol functions. All DHCP servers have synchronized clocks (e.g., using NTP). Through these protocol sessions between pairs of servers, a server can inform other servers about new bindings or about lease extensions on existing bindings and can inform other servers about bindings that have been released. The collection of bindings managed by the DHCP servers is essentially a distributed database. The servers can use the inter-server protocol to synchronize changes to the database and ensure coherency among the individual servers. However, latency in the synchronization process means that the bindings on some servers may be stale. Potentially, clients could receive invalid configuration Droms, Cole [Page 2] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 information based on these stale bindings. The inter-server protocol is designed to ensure that clients always receive valid configuration information. 1.1 Terminology This document uses the following terms: + "DHCP client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. + "DHCP server" A DHCP server is an Internet host that returns configuration parameters to DHCP clients. + "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers. + "Local Server" A Local Server (LS) references the particular server in question. + "Directly Connected Server" A Directly Connected Server (DCS) references servers which are directly connected to (or one hop removed from) the LS. + "Remote Server" A Remote Server (RS) references servers two or more hops removed from the LS. + "Server Group" A Server Group (SG) is the set of associated servers providing the redundant database for the common set of PCs, workstations, etc. 1.2 Protocol Goals Droms, Cole [Page 3] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 The DHCP inter-server protocol is developed with the following objectives: + Develop a highly available DHCP server architecture. + Maintain the client behavior in the current non-redundant DHCP protocol [1]. + Maintain the design goals of the DHCP Client/Server protocol as identified in [1]. + Maintain uniqueness of the assigned IP addresses. + Minimize changes to the behavior of the BOOTP Relay Agents. + Ease redundant server administration. Administration should be primarily isolated to a single server of the replica server group. Failure recovery should be automatic. The DHCP inter-server protocol provides the following functions: + Distribution of address assignment information, + Distribution of lease release (as a result of DHCPRELEASE) information, + Reallocation of available addresses and + Query about whether a specific address is "in use". 1.3 Approach Philosophy The remainder of the this document discusses the SCSP as applied the problem of developing the DHCP inter-server protocol. Two redundant server behavior models are developed; the Peer Redundant Server Model (PRSM) where all servers are roughly equivalent in their actions and the Primary/Secondary Redundant Server Model (PSRSM) where the primary server handles all interaction with the DHCP clients. Over time, one of the behavior models will be chosen and fully developed as the DHCP inter-server protocol. Section 2 of this document presents an overview of the SCSP protocol and a discussion of the issues to resolve in building the DHCP inter-server protocol on the SCSP capabilities. The issues to be resolved include the decision on the choice of the redundant server Droms, Cole [Page 4] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 behavior model for the DHCP inter-server protocol. Section 3 presents the Peer Redundant Server Model (PRSM) where all servers are roughly equivalent in their actions. Section 4 presents the Primary/Secondary Redundant Server Model (PSRSM). Here a primary server handles all the interaction with the DHCP clients, where changes to the client's binding are required. Included in the discussion of the PRSM and the PSRSM is a description of the ways in which DHCP servers will use the protocol to coordinate assignment, release and expiration of bindings to guarantee consistent interactions between DHCP servers and clients. These sections also contain a list of the open questions to resolve for the full development of the respective models. We anticipate that this list of open questions will be resolved in following drafts. Section 5 presents the DHCP specific Client State Advertisement and Client State Advertisement Summary records. These are required to map the DHCP inter-server protocol onto the SCSP capabilities. Section 6 contains conclusions. 2. Analysis of SCSP for DHCP Inter-server Protocol This section presents a brief overview of the SCSP protocol. Further details are found in the appendices and in Reference [2]. An analysis of the issues to resolve to build the DHCP inter-server protocol on top of the SCSP capabilities is presented following the SCSP Overview. 2.1 SCSP Overview The SCSP protocol consist of three separate sub-protocols, i.e., the status of the inter-server connection, + the "Cache Alignment" protocol: this protocol defines the cache synchronization capability for new servers and servers that, for whatever reason, have lost synchronization, and + the "Client State Update" protocol: this protocol provides the ongoing server cache synchronization through asynchronous client state updates. These sub-protocols define the semantics and high-level syntax of generic message sets and their exchanges in support of the capabilities provided. The SCSP associates replica databases into Server Groups. The SCSP supports both point-to-point and point-to- multipoint connections between the LS and the DCS(es). We discuss each of these sub-protocols in more detail in the appendices below. Droms, Cole [Page 5] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 For now we accept that these capabilities are generically provided and analyze possible redundant DHCP server overlays on top of the SCSP. Within DHCP, the notion of SCSP Server Groups (SG) is defined by those servers supporting a common set of client PCs, workstations, etc. Then, in general we have multiple redundant servers supporting distinct sets of client PCs which may be remote from their supporting servers. Logically, the remote PCs are connected to their geographically dispersed servers via DHCP relay agents and IP transport. The relay agents may have multiple interfaces to the network. For discussion purposes we say that SG A supports the client base A, SG B supports the client base B and so on. Relay agents A1, A2, servers A1, A2, ... 2.2 Issues to Resolve for DHCP Inter-server Protocol Development The SCSP does not fully define the redundant DHCP inter-server protocol. It does provide an underlying capability. Several issues must by addressed in order to fully define the DHCP inter-server protocol. These include: + What behavior model will the redundant servers within a SG employ? + Can the DHCP inter-server protocol be developed without modifying the behavior of the relay agents and the clients? + How do servers in the SG identify a "failed" server? + What are the DHCP protocol specific client state records defined in SCSP? + How does SCSP support the synchronization of pre-configured (or provisioned) database information? + What is the nature of the server-to-server connection? + What topologies will be supported? We discuss each of these separately below. Within each of the appendices, which present short overviews of the SCSP sub-protocols, further elaboration on some of the above issues is provided. 2.2.1 What behavior model will the redundant servers within a SG employ? Droms, Cole [Page 6] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 Two distinct models are Peer Behavior and Primary/Secondary Behavior. These two models are more fully developed in Sections 3 and 4 respectively. 2.2.2 How do servers in the SG identify a "failed" server? the LS know that the DCS is disconnected from the client pool associated with their SG? Does the fact that the LS is disconnected from the DCS yet connected to the client pool indicate that the DCS is necessarily disconnected from the client pool? I.e., does routing transitivity hold? 2.2.3 Can the DHCP inter-server protocol be developed without modifying the behavior of the relay agents and the clients? In particular, when a server fails and another server picks up its bindings, how does the client lease extensions, lease releases,etc. get to the new server? Does the relay agent replicate the messages to all servers in a Server Group? How do the servers within a single Server Group respond to client requests, discovery, extension, release? In [3] there is a discussion of a Relay Agent caching an association between a client and a server for the duration of the lease to help provide some load sharing capabilities. If this is in fact implemented, then the Relay Agent would have to move this to the backup server in the event the client server failed. 2.2.4 What are the DHCP protocol specific client state records defined in SCSP? The SCSP defines a generic message set and semantics and associated client state records. The specifics of the DHCP bindings must be mapped into this message set and client records. Specifically, it is required to define the DHCP protocol specific CSAS and CSA records which are part of the CA and CSU messages, respectively. Loosely, the CSA record within a DHCP implementation is the client binding and the CSAS is a summary message and pointer to the CSA on the originating server. 2.2.5 How does SCSP support the synchronization of pre-configured (or provisioned) database information? The Client State Advertisement (and Summary) records are explicitly defined to support client requested bindings (or summaries). But there is information provisioned into DHCP servers which must be distributed to a new replica server. How this information is replicated needs definition within the DHCP inter-server protocol Droms, Cole [Page 7] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 through the exchange of SCSP messages. 2.2.6 What is the nature of the server-to-server connection? SCSP was developed within the ION working group and relies on an underlying layer two connection existing. What is the nature of the corresponding connection for the DHCP server-to-server case? Is it none, i.e., simple UDP/IP connectivity? (Are the acknowledgment and timeout procedures within SCSP robust enough to run over UDP?) Or is it a TCP connection? (Need to define a TCP port number or dynamic assignment of the port for this protocol to run over.) 2.2.7 What topologies will be supported? The SCSP supports both point-to-multipoint and point-to-point connections between the LS and the DCS. It also supports full mesh and a partial mesh interconnection of servers within an SG. What impact on the system performance will these different topologies have? Each of the above issues must be addressed for the DHCP inter-server protocol independent of use the generic capabilities offered by SCSP. The value of the SCSP is that it provides the lower level connection maintenance, database synchronization and asynchronous database update capabilities that are required of any redundant server architecture. By relying on SCSP as the lower level synchronization capabilities, the work of defining the DHCP inter-server protocol is greatly simplified. This simplification would allow the working group to focus on resolving the DHCP inter-server protocol specific issues identified above, having the effect of accelerating the progress of this protocol development. 3. Peer Redundant Server Models In the Peer Redundant Server Model (PRSM) all servers of the SG behave roughly identically. Each can respond to the initial DHCPREQUESTs of the clients, each is the owner of their particular bindings, etc. They all are capable of randomly servicing clients from a pool and all are responsible to propagate the binding information within the SG. This model has the advantages that it provides load balancing and a graceful fault recovery (once defined). It has the disadvantages that it is harder to ensure non-duplicate address assignments and the client bindings are distributed potentially making fault isolation more difficult. 3.1 PRSM Description Droms, Cole [Page 8] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 The PRSM supports multiple servers within a single SG. Within the SG the actions and behavior of all servers are roughly equivalent to one another. Any of the servers can handle the DHCP client server interactions. The servers within the SG maintain sufficient TCP connectivity that the resultant graph spans the set of servers in the SG. All DHCP servers within the SG have synchronized clocks, e.g., using NTP. The Relay Agents forward messages to all servers in the SG. The approach proposed for the PRSM, which we believe is conceptually the easiest to develop, is that 1) unallocated addresses belong to different servers (however, they can be redistributed through the Address Redistribution Procedure), and 2) once a binding is made, and for the duration of that binding, it 'belongs' to that server (unless the server dies or becomes disconnected for its set of clients). States in which the bound client unicasts back to that server are handled sufficiently well with this approach. (Note: There are probably failure scenarios where the client unicasts back, e.g., sends a DHCPDECLINE from the REQUESTING-state or a DHCPRELEASE from the BOUND-state, to a server which has recently died that need to be thought through in some detail.) Client states where the bound client broadcast back to the SG are handed somewhat differently. In this case, only the owner of the binding should respond if a change to the binding is requested, e.g., a lease extension. If a change to the binding is not required, e.g., the client is in the INIT-REBOOT- state and is only verifying an existing binding, then any of the servers may respond. When a server dies (or becomes disconnected), the bindings (and unallocated address) belonging to it are passed to another server of the SG according to some rule. The rule could be a simple list administered into the definition of the SG which defines which server is to pick up the bindings belonging to the dead (or disconnected) server. (We suspect that this new server should change the and should propagate these new CSA records to the other servers in the SG.) Therefore, this model relies on the notion of server 'ownership' of the client binding. The ownership is communicated through the Prior to committing any change to a client binding, e.g., sending a DHCPACK, the LS must communicate this information with at least one DCS in the SG. This may cause excessive delay in servicing DHCP client requests. However, this is necessary to guarantee that no duplicate address assignments occur. The advantage of requiring forwarding to only one backup server is that this scales well as the number of servers in a SG grows; you do not have to forward to all servers in a SG. There are performance improvements possible in an implementation, e.g., your could forward to two, but wait for the Droms, Cole [Page 9] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 acknowledgment from only one. Therefore, if you are running this protocol over noisy facilities, this would improve the probability of getting the forwarding out to at least one other server the first time. When a server boots and establishes connectivity to the other servers in the SG or re-establishes connectivity to other servers in the SG, it synchronizes its cache according to the cache alignment protocol as describe in [2]. When a server looses connectivity to another server, it should check to see if it is picking up the ownership of the dead server. If so, it should appropriately modify the CSA records associated with the dead server. It should then force the SCSP cache alignment process with each of its remaining DCS prior to servicing any further client messages. (Note: we're assuming there a mechanism to force the cache alignment process?) The available address pool is distributed over the peer servers in the server group. Each unallocated address 'belongs' to a specific server. The Address Redistribution Procedure distributes unallocated addresses to the peer servers. If a server runs low of unallocated addresses it can request additional unallocated addresses through the Address Redistribution Procedure. If it is out of unallocated addresses, it must obtain more before it can make DHCPOFFERS. This effectively decouples the servicing of clients from the request for unallocated addresses and should provide better performance and scaling. In the event of a server failure, the unallocated addresses associated with the failed server must be available to another server or servers in the SG. These addresses are passed to another server in the server group along with the bindings which belonged to the failed server according to a rule as discussed above. Unallocated addresses are redistributed by the Address Redistribution Procedure on a need be basis. The Address Redistribution Procedure is TBD. 3.2 Protocol actions There are several DHCP protocol interactions that can change the address assignment information managed by DHCP servers: + New address assignment + Lease extension + Lease expiration Droms, Cole [Page 10] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 + RELEASE In the remainder of this section, each case is discussed along with PRSM actions to avoid passing invalid configuration information to clients. Server actions which do not change the nature of a binding, e.g., binding verification requests from a client in the INIT- REBOOT-state, can be serviced by any of the servers in the SG. 3.2.1 New Address Assignment When a DHCP server assigns a new IP address to a DHCP client (as part of an INIT-state transaction), the server adds that assignment to its local database of bindings. The server must use an IP address that is available for assignment from its local address pool and must inform at least one of the other DHCP servers about the newly created binding by completing the transmission of a CSU message containing the CSA record to the other server or servers. These actions must be completed just prior to sending the DHCPACK. The SCSP protocol requires the DCS(s) to forward this CSU throughout the remainder of the SG. (Note: Specify the options/type/priority fields in the CSA message.) To identify an IP address that may be assigned to the new client, the server picks an address from its local pool of assignable addresses (as described in the Address Redistribution Procedure) that is not currently in the server's list of bindings. If the server is 'low' on available address for assignment, it should initiate the Address Reassignment Procedure (soon after servicing the immediate client request) in order to obtain additional address. If no addresses are available for local assignment, no DHCPOFFER can be sent to the client. 3.2.2 Lease Renewal A DHCP server may choose to extend the lease of a DHCP client in response to a DHCPREQUEST message from a client in INIT-REBOOT-state. This server must be the 'owner' of the client binding. This lease extension is propagated by the extending server to at least one other server by successfully transmitting a CSU message containing the CSA record with the lease extension. This must happen prior to the server transmitting the DHCPACK to the client. The SCSP protocol ensures the propagation of this information to all servers in the SG. DISCUSSION: The details of this propagation require a little care in their Droms, Cole [Page 11] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 design. The delay between lease extension and distribution to other servers leaves a window in which some servers may have different lease expiration times for a particular binding. During that window, a client may reboot and get an old lease expiration date or a server may determine that a lease has expired (based on an old lease expiration date) after it has been extended on another server. If a client receives an old expiration date (that has not been extended), the client will reset its expiration date to that old value. If the lease is sufficiently close to expiring, the client will use DHCP to extend the lease. Even if this extension takes place on a different server, the servers will eventually converge to agree on the expiration time last issued to the client. A server may determine that a lease has expired prior to notification of the extension of that lease. If the server takes no explicit action other than to delete the expired binding from its database, the extended lease will propagate to the server from the extending server. The following section describes lease expiration in more detail. It is hoped that this issue can be resolved by employing the notion of binding ownership, e.g., lease extensions should not happen without explicit communication with the server currently owning the CSA record. The details need to be worked out and changes to this section made. 3.2.3 Lease Expiration When a DHCP server determines that the lease on a binding has expired, the server simply drops that binding from its database and takes no other explicit action. The address in that binding is available to be allocated to another client at this time by the server owning that unallocated address. DISCUSSION: If a server takes no other specific action than to delete the binding from its database, premature expiration (expiration based on a stale expiration date) will have no effect. The extending server will distribute the information about the lease extension to the other servers, synchronizing all of the other servers to the new expiration date. The only potential problem arising from premature expiration is reassignment of an address that is still in use. The notion that a server owns the client binding and the associated address should Droms, Cole [Page 12] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 eliminate the possibility of this situations from occurring. 3.2.4 Lease RELEASE When a DHCP server receives a DHCPRELEASE from a client and the server is the owner of that client binding, the server should expire that binding and transmit a CSU message containing the CSA record of the release notification to at least one of the other servers in the SG. The other servers discard the binding record from their databases upon receipt of the CSA record containing the DHCPRELEASE notification. If the RELEASEing server discovers any other server that has responded to a DHCPREQUEST message from the DHCP client for the RELEASEd address after the RELEASE message was received, the client is still using the address and the lease is still valid. In this case, the server that has responded to the DHCPREQUEST message retains the ownership of the binding and distributes that binding to at least one of the other servers. DISCUSSION: The case discussed in the second paragraph is actually a DHCP protocol error on the part of the client; after issuing a DHCPRELEASE, the client MUST go to INIT-state and request a new address. However, as there is no mechanism in DHCP through which the server can inform the client of such an error, the servers must accommodate the error and maintain the consistency of the binding database. In the event that the original server has died prior to receiving a RELEASE message from the client, the RELEASE message will not be propagated to the remaining servers. This is due to the fact that the RELEASEing client unicasts the message to the dead server. The implications of this need to be fully determined. Currently, no actions are defined to try to 'capture' the client RELEASE by another server in the SG. 3.3 Address Redistribution Procedure This procedure is TBD. Several requirements imposed on this procedure are identified in the above PRSM. These include: + The redistribution procedure must be capable of distributing the unallocated addresses at SG initialization or when initializing a Droms, Cole [Page 13] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 new server of the SG. + The redistribution procedure should fairly distribute unallocated addresses. DISCUSSION: The Address Redistribution Procedure has not been fully thought out. However, the procedure may be as simple as the following algorithm. A server which realizes that it is low on unallocated addresses (associated with a given subnet), may initiate a request to DCS(s) for more unallocated addresses. A server may find itself in this situation either at initialization time, reboot, or by allocating most of its owned addresses. The server then goes down its list of DCS(s). For each DCS, the LS sends a request for additional addresses. Contained in this request is the number of unallocated addresses it currently owns, say n. The receiving DCS compares this to its number of unallocated addresses, say m. If m > n, then the DCS must respond to the LS with (m - n)/2 addresses. If m < n, then the DCS may request the LS to provide it with (n - m)/2 addresses. The LS continues this procedure until it has corresponded with each of its DCS(s). To avoid situations/conditions where addresses are sparse and potential battles for addresses would occur, there probably needs to be some sort of throttling mechanism to slow down the requests. 3.4 Open Questions for the PRSMs + Are these the only cases in which binding information may become out of date? + Are these solutions correct? + Need to fully develop procedures for DHCPDECLINE, DHCPRELEASE and all 'lost' packet and failure scenarios. + Servers cooperating to achieve "fair" distribution of available addresses through the Address Redistribution Procedure. + Can a cache alignment process be 'simultaneously' imposed on all servers in the SG? The philosophical approach taken in defining the actions of the assigning server is to force it to inject the information into at least one other server in the SG just prior to committing a change in a client state, e.g., an IP address assignment, a lease extension, etc. Then, force all servers to go into a Droms, Cole [Page 14] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 'simultaneous' cache alignment process in the event of a server failure in the group to ensure that the most recent CSA records are fully propagated prior to further assignments or extensions being made by the group. This is to ensure non-duplicate address assignments. But the specifics of how to force a 'simultaneous' cache alignment is to be determined. + User intervention in case of database incoherency Fixing the collective database on the DHCP servers in case of a problem could be a *real* nightmare. + DHCP server maintenance There is likely an opportunity for the development of a server management tool that would download the database information from all servers and check for conflicts/inconsistencies such as assignment of an IP address to multiple clients, bindings that are not replicated across all servers, bindings that have inconsistent lease expiration times, etc. 4. Primary/Secondary Redundant Server Models In the Primary/Secondary Behavior model, a single server in the SG is primary and is responsible for servicing all client PCs and to distribute this information to the other servers. All other servers are secondary. Secondary servers may participate in client/server interactions when no modification to an existing binding is required, e.g., a client verification request. When the primary server fails, one of the secondary servers becomes the new prime. One mechanism to elect the primary server within an SG is described in Appendix C of [2]. Another mechanism is to simply define through an administrative rule the order of ascension. Currently, the Primary Election Process for the PSRSM is to be determined. This model has the advantage of being conceptually simple to discuss, minimizes issues associated with duplicate address assignments and isolates the ownership of the bindings to a single server at any point in time. It has the disadvantages of not fully supporting load balancing. 4.1 PSRSM Description The PSRSM supports multiple servers within a single SG. Within the SG a single server acts as the "Primary" server; all other servers act as "Secondary" servers. The Primary server is responsible for handling all DHCP client server interactions which require a change to a client binding. The role of the secondary servers is to maintain a redundant server cache in the event that the primary server fails. Droms, Cole [Page 15] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 However, if a change to the binding is not required, e.g., the client is in the INIT-REBOOT-state and is only verifying an existing binding, then any of the secondary servers may respond as well. The servers within the SG maintain sufficient TCP connectivity that the resultant graph spans the set of servers in the SG. All DHCP servers within the SG have synchronized clocks, e.g., using NTP. The Relay Agents forward messages to all servers in the SG. Prior to committing to any change in a client binding, e.g., sending a DHCPACK, the Primary server must communicate this change to at least one secondary DCS. This may cause excessive delay in servicing DHCP client requests. However, this is necessary to guarantee that no duplicate address assignments occur. The advantage of requiring forwarding to only one backup server is that this scales well as the number of servers in a SG grows; you do not have to forward to all servers in a SG. There are performance improvements possible in an implementation, e.g., your could forward to two, but wait for the acknowledgment from only one. Therefore, if you are running this protocol over noisy facilities, this would improve the probability of getting the forwarding out to at least one other server the first time. Within this model, ownership of a client binding always resides with the Primary server. Because the Primary server is solely responsible for the servicing of all client requests which require changes to be made to the client binding, it can potentially represent a performance bottleneck. A possible solution to this problem is to limit the number of subnets (and hosts) supported by a SG in the PSRSM. However, in situations where the majority of the client/server interactions are related to verification of existing bindings, load balancing can occur because the secondary servers may respond to these client requests as well as the primary server. When a server boots and establishes connectivity to the other servers in the SG or re-establishes connectivity to other servers in the SG, it synchronizes its cache as describe in [2]. A newly established (or reconnected) server within the SG can initiate the Primary Server Election Process. The Primary Server Election Process is TBD (one such election process is discussed in the Appendix C of [2].) When a secondary server or group of secondary servers become disconnected from the primary server (for whatever reason), they initiate the Primary Server Election Process. The servers can be disconnected for many reasons, e.g., a failure of the primary server process or a network failure causing the connection to be dropped. When a secondary server becomes disconnected from other secondary servers this is not cause to initiate the Primary Server Election Process. Once the primary server is newly elected, it should go Droms, Cole [Page 16] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 through the SCSP cache alignment protocol with each of the remaining secondary servers prior to servicing client messages. (Note: we're assuming there a mechanism to force the cache alignment process?) (Note: There are probably failure scenarios where the client unicasts back, e.g., sends a DHCPDECLINE from the REQUESTING-state or a DHCPRELEASE from the BOUND-state, to a server which has recently died that need to be thought through in some detail.) 4.2 Protocol Actions There are several DHCP protocol interactions that can change the address assignment information managed by DHCP servers: + New address assignment + Lease extension + Lease expiration + RELEASE In the remainder of this section, each case is discussed along with PSRSM inter-server protocol actions to avoid passing invalid configuration information to clients. Server actions which do not change the nature of a binding, e.g., binding verification requests from a client in the INIT-REBOOT-state, can be serviced by any of the servers in the SG. 4.2.1 New Address Assignment Just prior to sending the DHCPACK, the primary server completes the transmission of a CSU message containing the CSA record for the client binding to at least one of the secondary DCSs. The SCSP protocol requires the DCS(s) to forward this CSU throughout the remainder of the SG. (Note: Specify the options/type/priority fields in the CSA message.) If a newly elected Primary server receives a DHCPREQUEST with a 'server identifier' other than its own, it should respond to this DHCPREQUEST. (How would this currently happen?) 4.2.2 Lease Renewal Just prior to sending the DHCPACK, the primary server completes the transmission of a CSU message containing the CSAS record for the renewed client binding to at least one of the secondary DCSs. The SCSP protocol requires the DCS(s) to forward this CSU throughout the Droms, Cole [Page 17] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 remainder of the SG. (Note: Specify the options/type/priority fields in the CSA message.) 4.2.3 Lease Expiration When the primary server determines that the lease on a binding has expired, the server simply drops that binding from its database and takes no other explicit action. The address in that binding may be assigned to a new client at this time. When a secondary server determines that the lease on a binding has expired, the server simply drops that binding from its database and takes no other explicit action. 4.2.4 Lease RELEASE When a primary server receives a DHCPRELEASE from a client, the primary server completes the transmission of a CSU message containing the CSAS record for the released client binding to at least one of the secondary DCSs. The servers discard the lease from their databases. DISCUSSION: There are probably failure scenarios where the client unicasts back, e.g., sends a DHCPDECLINE from the REQUESTING-state or a DHCPRELEASE from the BOUND-state, to a server which has recently died that need to be thought through in some detail. In this case, there is no mechanism currently defined for the newly elected primary server to receive the client's RELEASE message. 4.3 Primary Server Election Process The Primary Server Election Process is to be determined. DISCUSSION: However, this may be as simple as defining an 'administrative rule' to determine the order of succession (as discussed above in the case of passing binding ownership in the PRSM above). Or this may be more automatic through the definition of an election process, such as that identified in the appendix of [2]. 4.4 Open Questions for the PSRSM + Can a cache alignment process be 'simultaneously' imposed on all servers in the SG? Droms, Cole [Page 18] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 The philosophical approach taken in defining the actions of the assigning primary server is to force it to inject the information into at least one other server in the SG just prior to committing a change in a client state, e.g., an IP address assignment, a lease extension, etc. Then, force all servers to go into a 'simultaneous' cache alignment process in the event of a primary server failure in the group to ensure that the most recent CSA records are fully propagated prior to further assignments or extensions being made by the group. This is to ensure non-duplicate address assignments. But the specifics of how to force a 'simultaneous' cache alignment is to be determined. + Need to define the new primary server election process. + Need to fully develop procedures for DHCPDECLINE and all 'lost' packet scenarios and failure scenarios. 5. DHCP Specific CSA and CSAS Records This section presents the CSA and the CSAS records specific to the DHCP inter-server protocol. These records apply to both the PRSM and the PSRSM and so are presented separately in this section. The assumptions made in defining the DHCP client/server protocol specific records are the following: + Must provide the capability for the auto-configuration of a new server. One ancillary use of the inter-server protocol is in configuring new DHCP servers. The DHCP inter-server protocol should allow the download of a server's configuration file and to allow addition of a new server to the list of DHCP servers. A new server might be configured by simply giving it the address of an existing server. The new server could then download a list of all other known servers, the pool of candidate addresses, any special configuration information (e.g., vendor class information) and the existing bindings. The new server could also announce itself to all of the other existing servers. + A 'boot record' is required which carries the provisioned portion of the DCHP server cache. This is the information which contains the administrative information defining the address range, 'scopes', registered clients', etc. It is assumed that this record is vendor specific (because of the different implementations of the server configuration files) and will be defined as such. This boot record will satisfy the capabilities discussed in the previous bullet item. (Note: this requires a lot Droms, Cole [Page 19] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 more thought.) + The CSAS and the CSA records are maximally defined at this point. Because clients DHCPDISCOVERY messages can contain client specific requests for parameters, it is necessary to embed the full set of options (committed to the client in the DHCPOFFER message) within the CSA record. If it is determined at a later date, that there is information in the CSA records which are locally derivable, then this information will be removed from the definition of the CSA records. 5.1 CSAS Records According to the semantics of the CSAS record defined in [2], the CSAS record should maximally contain the 'CSA Sequence Number', the 'Search String' and the server 'Originator ID'. Further, the sequence number is defined in the generic portion of the CSAS record; only the search string and the originator ID are DHCP protocol specific. The format of the CSAS record for the DCHP inter-server protocol is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSA Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |type | state | htype | hlen | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chaddr (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ciaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server ID (encoded as in BOOTP options, tag=54) (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional ClientID (encoded as tag=61) (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Option (encoded as in BOOTP options, tag=255) (1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.1-1 DHCP inter-server CSAS record format where CSA Seq.No - is part of the generic SCSP CSAS record format defined in [2] type - represents the type of the CSAS record, e.g. client, boot Droms, Cole [Page 20] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 state - represent the state of the (client) record, e.g., reserved, unbound, bound, extended htype - hardware address type (defined in [4]) hlen - hardware address length chaddr - client hardware address ciaddr - client IP address (if assigned). If not assigned, this field is all 0s. Server ID - the Server ID encoded as in the DHCP options and BOOTP vendor extensions defined in [3]. (Optional) Client ID - this field is the optional Client ID encoded as in the DHCP options and BOOTP vendor extensions defined in [3]. If present, the Client ID is the 'search string'. End option - determines the end of the CSAS record The CSA sequence number is part of the generic CSAS record defined in [2]. The remainder of the CSAS record is the client/server protocol specific portion of the record. The portion beginning with the Server ID is encoded as defined in the DHCP Options and BOOTP Vendor Extensions in [3] using a 'tag, length, variable' encoding scheme. DISCUSSION: The inclusion of the 'type' and 'state' fields needs more thought. There is a desire to provide the capability to dynamically propagate boot files between servers. There are probably other ways to indicate the fact that the CSAS records points to a 'boot file' versus a 'client record', but it is felt that this is the most straight forward. The record identified above is really meant to represent the format for a 'client record', not the 'boot file' record. However, the format of the 'boot file' record is to be determined. The SCSP CSA record supports fragmentation (with a fragmentation sequence number field of 15 bits). Therefore, a CSA record could accommodate a large boot file transfer. The 'state' filed was included currently as a place holder. There may be a need to be able to explicitly identify the state of a client record. This field is placed here in anticipation of this requirement. Droms, Cole [Page 21] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 The SCSP requires only the 'search string', the sequence number and the Originator ID (here the Server ID). The Client ID option was included because it is allowed in the DHCP protocol and is used as the 'search string' if it is included. The default 'search string' is the chaddr plus ciaddr combination. In the event that the ciaddr is not assigned to the client, this field is all 0s. 5.2 CSA Records The format of the CSA record for the DCHP inter-server protocol is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Fragment Number | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSA Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |type | state | htype | hlen | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chaddr (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ciaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease Time Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server ID (encoded as in BOOTP options, tag=54) (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address Lease Time (encoded as tag=51) (6 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional ClientID (encoded as tag=61) (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Option (encoded as in BOOTP options, tag=255) (1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5.2-1 DHCP inter-server CSA record format where F - final bit, used to indicate the last fragment of a record Fragment Number - sequence number of the various fragments of a fragmented CSA record TTL - time to leave for a packet. This represents the number of Droms, Cole [Page 22] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 hops that a CSA takes before it is dropped. At each server that the CSA record traverses, the TTL is decremented by one. CSA Seq.No - is part of the generic SCSP CSAS record format defined in [2] Server Group ID - a 32-bit identification field that uniquely identifies both the client/server protocol for which the servers of the SG are being synchronized, e.g., DHCP, as well as the instance of that protocol. This implies that multiple instances of that same protocol may be in operation at the same time and have their servers synchronized independently of each other. type - represents the type of the CSAS record, e.g. client, boot state - represent the state of the (client) record, e.g., reserved, unbound, bound, extended htype - hardware address type (defined in [4]) hlen - hardware address length chaddr - client hardware address ciaddr - client IP address (if assigned). If not assigned, this field is all 0s. Lease Time Stamp - a time stamp indicating when the lease was made to the client. The specifics of this field are to be determined. The intent of this field is to allow another server (e.g., a newly booting server) to be able to determine the time this client's leave should expire (given as the sum of the Lease Time Stamp and the IP Address Lease Time below). Server ID - the Server ID encoded as in the DHCP options and BOOTP vendor extensions defined in [3] IP Address Lease Time - the IP Address Lease Time encoded as in the DHCP options and BOOTP vendor extensions defined in [3] (Optional) Client ID - this filed is the optional Client ID encoded as in the DHCP options and BOOTP vendor extensions defined in RFC 1533. If present, the Client ID is the 'search string'. Remaining Options - any remaining options carried in the original DHCPOFFER message to the client encoded as in the DHCP options and BOOTP vendor extensions defined in [3] Droms, Cole [Page 23] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 End option - determines the end of the CSAS record The F-bit, Fragmentation Number, TTL, CSA sequence number and Server Group ID are part of the generic CSA record defined in [2]. The remainder of the CSA record is the client/server protocol specific portion of the record. The portion beginning with the Server ID is encoded as defined in the DHCP Options and BOOTP Vendor Extensions in [3] using a 'tag, length, variable' encoding scheme. DISCUSSION: As discussed in the previous section on the CSAS record format, the format shown above is intended to be the client-type CSA record. Given a desire to support automatic booting of new servers and that the intent here is to support this boot file exchange through the CSA record, the definition of the bootfile-type CSA record needs to be defined. This will probably be vendor specific and will probably rely on the fragmentation capability of the CSA record provided for in the SCSP [2]. 5.3 Open Questions with the CSAS and CSA Records The following questions are identified as outstanding issues to be resolved for the CSAS and CSA record definitions to be considered complete: + Is the right approach for new server boot file transfers to rely on the CSA records defined within the SCSP? + Is it necessary to communicate the 'state' field information in the CSAS and CSA records? + How should the Lease Time Stamp be encoded? 6. Conclusion To be determined. Appendix A: The SCSP "Hello" Sub-protocol Overview The function of the SCSP "Hello" protocol is to monitor the status of the LS to DCS connection. The LS must be configured with the addresses of its DCSs. For each DCS (whether the low level Droms, Cole [Page 24] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 connection is point-to-point or point-to-multipoint), the LS maintains an Hello Finite State Machine (HFSM). The HFSM is shown in the figure below. +---------------+ | | +-------@| DOWN |@-------+ | | | | | +---------------+ | | | @ | | | | | | | | | | | | | | @ | | | +---------------+ | | | | | | | WAITING | | | +--| |--+ | | | +---------------+ | | | | @ @ | | | | | | | | | @ | | @ | +---------------+ +---------------+ | BIDIRECTION |----@| UNIDIRECTION | | | | | | CONNECTION |@----| CONNECTION | +---------------+ +---------------+ Figure A-1 The Hello Finite State Machine Key: 1: Link layer connection is established 2: Transition based upon the receipt of a Hello message (and whether the LS ID is found in the Rec ID portion of the message 3: Hello Interval * Dead Factor exceeded 4: Loss of link layer connectivity The LS to DCS connections are initialized into the down state. The numbers in the figure refer to the actions discussed in the Key that cause a transition in the HFSM. The Hello protocol employs poll messages to monitor the status of the LS to DCS connections. The format of the Hello message is shown below. Droms, Cole [Page 25] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS ID | RecID1, .....RecIDn | Hello Int | Dead Factor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A-2 Hello message format The first field contains the LS ID. The following fields contain the ID s of the DCS s that the LS has received a Hello message from. The LS' HFSM uses these ID s to determine the status of the HFSM for each of the DCS s. Multiple DCS ID s are present in order to support point-to-multipoint connections. The following field is the Polling Interval and the last field is a Dead Factor. The product of the Polling Interval and the Dead Factor determines the length of time that the HFSM will hold open a connection without receiving a Hello from a peer DCS and transitioning the HFSM for that DCS to the Wait state. Issues to resolve for DHCP Server-to-Server Implementation: + The transition from the Down to the Wait state is made when the link level connection between the servers is made. The DHCP inter-server protocol needs to generalize this trigger because the path between redundant DHCP servers may not be a link level virtual circuit. Possible triggers include a) the establishment of a TCP session between the servers or b) the return of a ping off the distant server. Appendix B: The SCSP "Cache Alignment" Sub-protocol Overview The Cache Alignment protocol supports the initial server cache synchronization process of an LS with its DCSs. This process may occur at initial boot time of the server, at reconnect time of the server to the network, or other possible initialization or failure recovery scenarios. Like the Hello protocol, the Cache Alignment (CA) protocol maintains a Cache Alignment Finite State Machine (CAFSM) for each of its DCSs to monitor the status of its cache alignment. The figure below shows the CAFSM and indicates some of the triggers that would cause the state transitions to occur. Droms, Cole [Page 26] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 +------------+ | | +---@| DOWN | | | | | +------------+ | | | | | @ | +------------+ | |Master/Slave| |----| |@---+ | |Negotiation | | | +------------+ | | | | | | | | @ | | +------------+ | | | Cache | | |----| |----| | | Summarize | | | +------------+ | | | | | | | | @ | | +------------+ | | | Update | | |----| |----| | | Cache | | | +------------+ | | | | | | | | @ | | +------------+ | | | | | +----| Aligned |----+ | | +------------+ Figure B-1 Cache Alignment Finite State Machine Key: 1: When HFSM reaches Bi-directional state 2: HFSM transitions out of Bi-directional state Droms, Cole [Page 27] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 3: Master/Slave relationship is established 4: Once both LS and DCS exchange CA messages, both with O-bit set to 0, then CRL is complete 5: E.g., Errored sequence number 6: Full cache update achieved Each of the CAFSMs is coupled with the respective HFSMs in the LS. The CAFSM is initialized in the Down state. It transitions to the Master/Slave Negotiation state when the corresponding HFSM transitions to the Bi-Directional state. The CAFSM transitions back to the Down state in the event that the corresponding HFSM transitions out of the Bi-Directional state. In the Master/Slave state the LS-DCS pair negotiate who is to be the master of the connection during the cache alignment process. In the Cache Summary state the LS/DCS pair exchange Client State Advertisement Summary (CSAS) records within the CA messages. The servers use these message exchanges to build a Client State Advertisement Request List (CRL). The CRL indicates the portions of the respective server caches that are out of alignment. The cache mis-alignment (as indicated in the local CRL) is resolved in the Update Cache state where the servers exchange full client state information in CSA records within the CSU messages, only where mis- alignment occurs. Once the CRL is resolved, the LS/DCS caches are aligned and the CAFSM transitions to the Aligned state. The protocol further defines the high-level syntax of a generic CA message. This format is shown in the figure below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS ID | DCS ID | CA Seq.No. | M-bit | I-bit | O-bit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B-2 Cache Alignment (CA) message format The message format consists of a CA Header followed by zero or more Client State Advertisement Summary (CSAS) records. The CA header consist of LS and DCS ID s , a Sequence Number, and an M, I, and O bits. The M bit indicates the Master/Slave relationship, the I bit indicates that the Master/Slave relationship is being negotiated and the O bit indicates more messages are to be exchanged. Issues to resolve for DHCP Server-to-Server Implementation: Droms, Cole [Page 28] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 The SCSP generic message syntax and semantics are defined, but not the detailed mappings required for the DHCP Server-to-Server implementation. Messages to be defined include: - Client State Advertisement Summary (CSAS) records within the Cache Alignment messages - Client State Advertisement (CSA) records within the Client State Update (CSU ) messages + Need to define the set of triggers which initiated the Client Alignment Protocol? Clearly on server boot initialization. But how does a well behaving server determine that due to network topology changes that it needs to trigger the Client Alignment Protocol ? + When building the CRL, the LS has to be able to determine, based upon the CSAS messages, that a particular client record is "out- of-date"? The SCSP defines the term "search string" which is the key word used to access the server cache, e.g., the client HW address for the DHCP implementation. The CA header also contains a sequence number which is monotonically increasing and is assigned by the originating LS (e.g., a primary DHCP server in the primary/secondary behavior model discussed above). The determination of the client state record's quality has to be specified. Appendix C: The SCSP "Client State Update" Sub-protocol Overview The purpose of the Client State Update (CSU) protocol is to provide a capability to constantly update the server caches through asynchronous CSU message exchanges. These updates are necessary because the status of the clients are in constant flux. Unlike the other two sub-protocols, the Client State Update protocol does not maintain a separate finite state machine. Instead, the activity of this protocol is tied to the CAFSM. Each CSU can contain zero or more Client State Advertisement records. The LS may send and receive CSUs when the corresponding CAFSM is in either the Aligned or the Cache Update states. The CSU protocol defines both CSU requests and reply messages. As consistent throughout the definition of the SCSP, the CSU protocol supports both point-to-point and point-to-multipoint connections. Issues to resolve for DHCP Server-to-Server Implementation: Droms, Cole [Page 29] DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997 The specific format of the Client State Advertisement (CSA) records within the CSU messages need to be defined for the DHCP implementation. References [1] Droms, R., "