draft-ietf-dhc-interserver-00.txt   draft-ietf-dhc-interserver-01.txt 
Network Working Group R. Droms Network Working Group R. Droms
INTERNET DRAFT Bucknell University INTERNET DRAFT Bucknell University
November 1996
Expires May 1997 R. Cole
AT&T MNS
March 1997
Expires August 1997
An Inter-server Protocol for DHCP An Inter-server Protocol for DHCP
<draft-ietf-dhc-interserver-00.txt> <draft-ietf-dhc-interserver-01.txt>
Status of this memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
skipping to change at page 1, line 33 skipping to change at page 1, line 37
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
The DHCP protocol is designed to allow for multiple DHCP servers, so The DHCP protocol is designed to allow for multiple DHCP servers, so
that reliability of DHCP service can be improved through the use of that reliability of DHCP service can be improved through the use of
redundant servers. To provide redundant service, all of the DHCP redundant servers. To provide redundant service, multiple DHCP
servers must be configured with the same information about assigned servers must carry the same information about assigned IP addresses
IP addresses and parameters; i.e., all of the servers must be and parameters; i.e., the servers must be configured with the same
configured with the same bindings. Because DHCP servers may bindings. Because DHCP servers may dynamically assign new addresses
dynamically assign new addresses or configuration parameters, or or configuration parameters, or extend the lease on an existing
extend the lease on an existing address assignment, the bindings on address assignment, the bindings on some servers may become out of
some servers may become out of date. The DHCP inter-server protocol date. The DHCP inter-server protocol provides an automatic mechanism
provides an automatic mechanism for synchronization of the bindings for synchronization of the bindings stored on a set of cooperating
stored on a set of cooperating DHCP servers. DHCP servers. The underlying capabilities of the DHCP inter-server
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 1. Introduction
DHCP servers manage the assignment of IP address and configuration DHCP servers manage the assignment of IP address and configuration
parameters to IP hosts. The DHCP protocol specification [1] refers parameters to IP hosts. The DHCP protocol specification [1] refers
to the collection of configuration information assigned to a client to the collection of configuration information assigned to a client
as a "binding". The DHCP protocol is designed to allow for multiple as a "binding". The DHCP protocol is designed to allow for multiple
DHCP servers, so that reliability of DHCP service can be improved 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.
DRAFT An Inter-server Protocol for DHCP November 1996 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.
through the use of redundant servers. To provide redundant service, The DHCP inter-server protocol uses TCP between pairs of servers.
all of the DHCP servers must be configured with the same information Each server is configured with a list of all other servers. The
about assigned IP addresses and parameters; i.e., all of the servers servers are also all configured with a pool of candidate IP addresses
must be configured with the same bindings. Because DHCP servers may that may be assigned dynamically to DHCP clients. Periodically or on
dynamically assign new addresses or configuration parameters, or demand, a server may contact one, some or all other DHCP servers to
extend the lease on an existing address assignment, the bindings on perform DHCP inter-server protocol functions. All DHCP servers have
some servers may become out of date. 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 DHCP inter-server protocol provides an automatic mechanism for The collection of bindings managed by the DHCP servers is essentially
synchronization of the bindings stored on a set of cooperating DHCP a distributed database. The servers can use the inter-server
servers. In section 2, this document outlines a proposal for a set protocol to synchronize changes to the database and ensure coherency
of functions provided by an inter-server protocol. Section 3 among the individual servers. However, latency in the
describes ways in which DHCP servers will use the protocol to synchronization process means that the bindings on some servers may
coordinate assignment, release and expiration of bindings to be stale. Potentially, clients could receive invalid configuration
guarantee consistent interactions between DHCP servers and clients.
Section 4 poses some open questions about the protocol as described DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
below.
information based on these stale bindings. The inter-server protocol
is designed to ensure that clients always receive valid configuration
information.
1.1 Terminology 1.1 Terminology
This document uses the following terms: This document uses the following terms:
o "DHCP client" + "DHCP client"
A DHCP client is an Internet host using DHCP to obtain A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address. configuration parameters such as a network address.
o "DHCP server" + "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "binding" + "binding"
A binding is a collection of configuration parameters, including A binding is a collection of configuration parameters,
at least an IP address, associated with or "bound to" a DHCP including at least an IP address, associated with or "bound to"
client. Bindings are managed by DHCP servers. a DHCP client. Bindings are managed by DHCP servers.
2. Protocol description + "Local Server"
The DHCP inter-server protocol includes the following functions: A Local Server (LS) references the particular server in
question.
DRAFT An Inter-server Protocol for DHCP November 1996 + "Directly Connected Server"
1. Distribution of address assignment information A Directly Connected Server (DCS) references servers which are
2. Distribution of lease release (as a result of DHCPRELEASE) directly connected to (or one hop removed from) the LS.
information
3. Reallocation of available addresses
4. Query about whether a specific address is "in use"
The protocol uses TCP between pairs of servers. Each server is + "Remote Server"
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,
can inform other servers about bindings that have been released and
can search for IP addresses that are currently unused.
The collection of bindings managed by the DHCP servers is essentially A Remote Server (RS) references servers two or more hops
a distributed database. The servers can use the inter-server removed from the LS.
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
information based on these stale bindings. The next section reviews
specific cases in which bindings may change and ways in which servers
can use the inter-server protocol to ensure that clients always
receive valid configuration information.
3. Protocol actions + "Server Group"
There are several DHCP protocol interactions that can change the A Server Group (SG) is the set of associated servers providing
address assignment information managed by DHCP servers: the redundant database for the common set of PCs, workstations,
etc.
* New address assignment 1.2 Protocol Goals
* Lease extension
* Lease expiration
* RELEASE
In the remainder of this section, each case is discussed along with DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
inter-server protocol actions to avoid passing invalid configuration
information to clients.
DRAFT An Inter-server Protocol for DHCP November 1996 The DHCP inter-server protocol is developed with the following
objectives:
3.1 New address assignment + Develop a highly available DHCP server architecture.
When a DHCP server assigns a new IP address to a DHCP client (as part + Maintain the client behavior in the current non-redundant DHCP
of an INIT-state transaction), the server adds that assignment to its protocol [1].
local database of bindings. The server must use an IP address that
is available for assignment and must inform other DHCP servers about
the newly created binding. The assigning server uses the DHCP
inter-server protocol to contact each of the other servers to
distribute the information about the new binding.
To identify an IP address that may be used assigned to the new + Maintain the design goals of the DHCP Client/Server protocol as
client, the server picks an address from the pool of assignable identified in [1].
addresses (as described in section 2) that is not currently in the
server's list of bindings. The server then contacts each of the
other servers to query about the status of that address. If any of
the other servers respond that the address is "in use", the querying
server identifies a new candidate address and repeats the process. If
none of the other servers respond that the address is "in use", the
querying server may assign the address to the DHCP client.
DISCUSSION: + Maintain uniqueness of the assigned IP addresses.
As an optimization, information about new bindings need not be + Minimize changes to the behavior of the BOOTP Relay Agents.
forwarded to other DHCP servers immediately and can be distributed
periodically as a batch update. The primary drawback to delayed
propagation of new bindings is the lack of redundancy until the
new bindings are distributed to other servers. Even with delayed
propagation, the required check of candidate addresses will
prevent assignment of any IP address to different DHCP clients by
multiple servers.
As an optimization, DHCP servers may maintain a list of available + Ease redundant server administration. Administration should be
addresses that have been checked with other DHCP servers. When primarily isolated to a single server of the replica server group.
queried about the availability of an address, a server that has Failure recovery should be automatic.
such a list of previously checked addresses must either reply that
the addresses are "in use" or must remove the address from its
list and reply that the address is "not in use".
DHCP servers may also request available addresses from other The DHCP inter-server protocol provides the following functions:
servers. These addresses would be supplied (if available) from a
list of available addresses on the remote server.
A server MUST successfully contact all other servers before + Distribution of address assignment information,
reassigning an address.
DRAFT An Inter-server Protocol for DHCP November 1996 + Distribution of lease release (as a result of DHCPRELEASE)
information,
3.2 Lease renewal + 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
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.
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?
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
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
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
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
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 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. response to a DHCPREQUEST message from a client in INIT-REBOOT-state.
This lease extension is propagated by the extending server to other This server must be the 'owner' of the client binding. This lease
servers using the DHCP inter-server protocol. The details of this extension is propagated by the extending server to at least one other
propagation require a little care in their design; the servers must server by successfully transmitting a CSU message containing the CSA
agree on the expiration date currently held by the client. Thus, the record with the lease extension. This must happen prior to the
extending server must check with all other servers to determine the server transmitting the DHCPACK to the client. The SCSP protocol
lease expiration time that was issued last by any server; that last ensures the propagation of this information to all servers in the SG.
expiration must be propagated to all other servers.
DISCUSSION: DISCUSSION:
The delay between lease extension and distribution to other The details of this propagation require a little care in their
servers leaves a window in which some servers may have different
lease expiration times for a particular binding. During that DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
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 design. The delay between lease extension and distribution to
old lease expiration date) after it has been extended on another other servers leaves a window in which some servers may have
server. 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 If a client receives an old expiration date (that has not been
extended), the client will reset its expiration date to that old extended), the client will reset its expiration date to that old
value. If the lease is sufficiently close to expiring, the client value. If the lease is sufficiently close to expiring, the client
will use DHCP to extend the lease. Even if this extension takes will use DHCP to extend the lease. Even if this extension takes
place on a different server, the servers will eventually converge place on a different server, the servers will eventually converge
to agree on the expiration time last issued to the client. to agree on the expiration time last issued to the client.
A server may determine that a lease has expired prior to A server may determine that a lease has expired prior to
notification of the extension of that lease. If the server takes notification of the extension of that lease. If the server takes
no explicit action other than to delete the expired binding from no explicit action other than to delete the expired binding from
its database, the extended lease will propagate to the server from its database, the extended lease will propagate to the server from
the extending server. The following section describes lease the extending server. The following section describes lease
expiration in more detail. expiration in more detail.
3.3 Lease expiration 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 When a DHCP server determines that the lease on a binding has
expired, the server simply drops that binding from its database and expired, the server simply drops that binding from its database and
takes no other explicit action. The address in that binding may be takes no other explicit action. The address in that binding is
recovered at a later date, if needed, and will be checked according available to be allocated to another client at this time by the
to the rules in section 3.1 before reassignment. server owning that unallocated address.
DISCUSSION: DISCUSSION:
If a server takes no other specific action than to delete the If a server takes no other specific action than to delete the
binding from its database, premature expiration (expiration based binding from its database, premature expiration (expiration based
DRAFT An Inter-server Protocol for DHCP November 1996
on a stale expiration date) will have no effect. The extending on a stale expiration date) will have no effect. The extending
server will distribute the information about the lease extension server will distribute the information about the lease extension
to the other servers, synchronizing all of the other servers to to the other servers, synchronizing all of the other servers to
the new expiration date. the new expiration date.
The only potential problem arising from premature expiration is The only potential problem arising from premature expiration is
reassignment of an address that is still in use. The rules for reassignment of an address that is still in use. The notion that
checking an address prior to reassignment guarantee that no other a server owns the client binding and the associated address should
server will have a binding for reassigned address and that the
address is not in use prior to reassignment.
3.4 Lease RELEASE DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
When a DHCP server receives a DHCPRELEASE from a client, the server eliminate the possibility of this situations from occurring.
contacts all other servers to distribute the release notification.
The other servers discard the lease from their databases. The 3.2.4 Lease RELEASE
address will be recovered, if needed, for reassignment according to
the rules in section 3.1 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 If the RELEASEing server discovers any other server that has
responded to a DHCPREQUEST message from the DHCP client for the responded to a DHCPREQUEST message from the DHCP client for the
RELEASEd address after the RELEASE message was received, the client RELEASEd address after the RELEASE message was received, the client
is still using the address and the lease is still valid. In this is still using the address and the lease is still valid. In this
case, the server that has responded to the DHCPREQUEST message case, the server that has responded to the DHCPREQUEST message
retains the binding and distributes that binding to all of the other retains the ownership of the binding and distributes that binding to
servers. at least one of the other servers.
DISCUSSION: DISCUSSION:
The case discussed in the second paragraph is actually a DHCP The case discussed in the second paragraph is actually a DHCP
protocol error on the part of the client; after issuing a protocol error on the part of the client; after issuing a
DHCPRELEASE, the client MUST go to INIT state and request a new DHCPRELEASE, the client MUST go to INIT-state and request a new
address. However, as there is no mechanism in DHCP through which address. However, as there is no mechanism in DHCP through which
the server can inform the client of such an error, the servers the server can inform the client of such an error, the servers
must accommodate the error and maintain the consistency of the must accommodate the error and maintain the consistency of the
binding database. binding database.
4. Open questions 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.
* Are these the only cases in which binding information may become 3.3 Address Redistribution Procedure
out of date?
* Are these solutions correct? This procedure is TBD.
* INIT case needs EXISTING/NEW binding option Several requirements imposed on this procedure are identified in the
above PRSM. These include:
Because of the "lazy synchronization" of DHCP servers, it is + The redistribution procedure must be capable of distributing the
unallocated addresses at SG initialization or when initializing a
DRAFT An Inter-server Protocol for DHCP November 1996 DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
possible that some servers may know about an existing binding while new server of the SG.
others do not. As an optimization, DHCP clients should be able to
select between existing bindings and new bindings in DHCPOFFER
messages from servers. A new option could be defined to indicate
to the client whether a DHCPOFFER message represents a new or an
existing binding.
* Each server must know all other servers + The redistribution procedure should fairly distribute
unallocated addresses.
Requiring each server to know about every other server imposes DISCUSSION:
additional administrative overhead in the configuration of DHCP
servers. However, this configuration overhead is probably minimal
relative to any other configuration required for DHCP servers.
* Each server must contact all other servers before reassigning an The Address Redistribution Procedure has not been fully thought
address 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).
There is a potential issue here in which no new DHCP clients can be To avoid situations/conditions where addresses are sparse and
configured if any of the DHCP servers cannot be contacted. Servers potential battles for addresses would occur, there probably needs
can mitigate this problem by maintaining a list of pre-checked to be some sort of throttling mechanism to slow down the requests.
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 3.4 Open Questions for the PRSMs
the part of DHCP servers in response to situations in which a
server cannot contact all other servers.
* Servers cooperating to achieve "fair" distribution of available + Are these the only cases in which binding information may become
addresses out of date?
The protoocol may need additional mechanisms or definition of + Are these solutions correct?
default behavior through which servers cooperate among themselves
to ensure that each has a sufficient pool of prechecked-addresses
on each network.
* User intervention in case of database incoherency + 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
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 Fixing the collective database on the DHCP servers in case of a
problem could be a *real* nightmare. problem could be a *real* nightmare.
* Potential deadlock in checking address - suppose two servers check + DHCP server maintenance
the same address for reassignment simultaneously? 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.
* Potential configuration for new server? 4. Primary/Secondary Redundant Server Models
One ancillary use of the inter-server protocol might be in In the Primary/Secondary Behavior model, a single server in the SG is
configuring new DHCP servers. Suppose the inter-server protocol primary and is responsible for servicing all client PCs and to
were extended to allow download of a server's configuration file 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.
DRAFT An Inter-server Protocol for DHCP November 1996 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.
and to allow addition of a new server to the list of DHCP servers. 4.1 PSRSM Description
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.
* DHCP server maintenance 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.
There is likely an opportunity for the development of a server DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
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.
5. Acknowledgments 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.
Many of the ideas in this proposal are due to Jeff Mogul, Greg Prior to committing to any change in a client binding, e.g., sending
Minshall, Rob Stevens, Walt Wimer, Ted Lemon and the DHC working a DHCPACK, the Primary server must communicate this change to at
group. Thanks to all who have contributed their ideas and least one secondary DCS. This may cause excessive delay in servicing
participated in the discussion of the inter-server protocol. 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.
6. References 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.
[1] Droms, R., "<draft-ietf-dhc-dhcp-07.txt", Work in progress, 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
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
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?
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
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
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.
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
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]
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
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.
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.
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 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:
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:
DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
The specific format of the Client State Advertisement (CSA)
records within the CSU messages need to be defined for the DHCP
implementation.
References
[1] Droms, R., "<draft-ietf-dhc-dhcp-09.txt", Work in progress,
November 1996. November 1996.
7. Security Considerations [2] Luciani, J., Armitage, G., Halpern, J., "Server Cache
Synchronization Protocol (SCSP)", draft-ieft-ion-scsp-01.txt.
Not addressed - but needed, I suspect. [3] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", Internet RFC 1533, October 1993.
7. Author's information [4] Reynolds, J., Postel, J., "Assigned Numbers", Internet STD 2,
Internet RFC 1340, USC/Information Sciences Institute, July 1992.
[5] (reference to the NTP RFC?)
Security Considerations
Not currently addressed - but needed.
Acknowledgments
Many of the ideas in this proposal are due to Jeff Mogul, Greg
Minshall, Rob Stevens, Walt Wimer, Ted Lemon, John Carlson, Phil
West, Joel Halpern and the DHC working group. additional
discussions. Thanks to all who have contributed their ideas and
participated in the discussion of the inter-server protocol.
Author's Address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
DRAFT Analysis of SCSP for DHCP Redundant Servers 15 Mar 1997
Robert G. Cole
AT&T Laboratories
Managed Network Solutions Division
Rm. 3L-533
101 Crawfords Corner Road
Holmdel, NJ 07733
Phone: (908) 949-1950
EMail: rgc@qsun.att.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/