Network Working Group K. Kinnear
INTERNET DRAFT American Internet Corporation
R. Cole
AT&T MNS
R. Droms
Bucknell University
July 1997
Expires January 1998
An Inter-server Protocol for DHCP
<draft-ietf-dhc-interserver-02.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The DHCP protocol is designed to allow for multiple DHCP servers, so
that reliability of DHCP service can be improved through the use of
redundant servers. To provide redundant service, all of the DHCP
servers must be configured with the same information about assigned
IP addresses and parameters; i.e., all of the servers must be config-
ured with the same bindings. Because DHCP servers may dynamically
assign new addresses or configuration parameters, or extend the lease
on an existing address assignment, the bindings on some servers may
become out of date. The DHCP inter-server protocol provides an auto-
matic mechanism for synchronization of the bindings stored on a set
of cooperating DHCP servers.
This draft is a direct extension of draft-ietf-dhc-
interserver-00.txt, and represents the merging of ideas from both
Kinnear, Cole & Droms [Page 1]
DRAFT July 1997
draft-ietf-dhc-interserver-alt-00.txt and draft-ietf-dhc-
interserver-01.txt. The basic protocol semantics from draft-ietf-
dhc-interserver-alt-00.txt were used with the underlying message map-
ping to SCSP from draft-ietf-dhc-interserver-01.txt. Considerable
additional work has been included in this current draft in the area
of protocol correctness, detailed work on mapping the protocol to
SCSP, and organization of the draft itself.
1. Introduction
DHCP servers manage the assignment of IP address and configuration
parameters to IP hosts. The DHCP protocol specification [1] refers
to the collection of configuration information assigned to a client
as a "binding". The DHCP protocol is designed to allow for multiple
DHCP servers, so that reliability of DHCP service can be improved
through the use of redundant servers. To provide redundant service,
all of the DHCP servers must be configured with the same information
about assigned IP addresses and parameters; i.e., all of 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 remainder of this document is organized in the following sec-
tions:
2. Goals and Requirements
Defines the requirements and goals for the protocol. Discusses
limitations of the protocol. Also contains a definition of
several classes of failures as well as a list of specific fail-
ures (which provide a useful common ground for discussion).
3. Overview
Discusses in a general way the content of the information com-
municated between servers implementing this protocol as well as
the way that information is communicated.
Introduces the three aspects of the protocol: client binding
management, address management, and group management.
Kinnear, Cole & Droms [Page 2]
DRAFT July 1997
Defines some key concepts surrounding the allowable "states" of
an IP address, including extensions critical to the operation
of this protocol.
Gives a brief sketch of the actions required by this protocol
for each DHCP client request received by the server.
4. Client Binding Management
Discusses the fundamental messages used by this portion of the
protocol, and the ways in which these messages are combined to
form higher level operations. Required responses to incoming
client binding management requests are explained in this sec-
tion. The required responses to incoming DHCP client requests
are explained in Section 6 below.
5. Address Management
The fundamental messages used by the address management portion
of the protocol are explained, as well as how they are combined
into higher level operations. The required responses to incom-
ing address management requests are explained in this section,
while the required responses to incoming DHCP client requests
are explained in Section 6 below.
6. Actions in Response to DHCP Client Messages and Events
The required responses to incoming DHCP client messages and
events are discussed in this section.
7. Group Management
The fundamental messages and their combination into higher
level operations for the group management portion of the proto-
col are explained. The actions to take when receiving any of
these messages as well as how to utilize them to join or leave
a server group are explained.
8. SCSP Message Mapping
The messages described in sections 4, 5, and 7 are mapped into
underlying SCSP messages in this section. This includes
detailed information on the format of each SCSP message.
9. IP Address State Transition
This protocol expands the possible states for an IP address.
The new states are described in Section 3.3. This section
Kinnear, Cole & Droms [Page 3]
DRAFT July 1997
describes all of the transitions between states in detail.
10. Security
The security implications of this draft are discussed in this
section.
11. Open Questions
Poses open questions about the protocol. Some questions from
draft-ietf-dhc-interserver-00.txt are included verbatim with
answers and questions (and some answers) new to this draft are
included as well.
12. Acknowledgments
13. References
14. Author's Information
A. Appendix A: An Overview of SCSP
1.1. The Language of Requirements
Throughout this document, the words that are used to define the sig-
nificance of particular requirements are capitalized. These words
are:
o "MUST"
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification.
o "MUST NOT"
This phrase means that the item is an absolute prohibition of
this specification.
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
o "SHOULD NOT"
Kinnear, Cole & Droms [Page 4]
DRAFT July 1997
This phrase means that there may exist valid reasons in particu-
lar circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the
case carefully weighed before implementing any behavior described
with this label.
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
1.2. Terminology
This document uses the following terms:
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configura-
tion parameters such as a network address.
o "client"
Whenever the term client is used in this draft, it refers to a
DHCP client (and not a server communicating with another server
using this protocol).
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "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.
o "active server"
An active server is one which is capable of offering IP addresses
to clients.
o "stable storage"
Kinnear, Cole & Droms [Page 5]
DRAFT July 1997
Every DHCP server is assumed to have some form of what is called
"stable storage". Stable storage is used to hold information
concerning IP address bindings (among other things) so that this
information is not lost in the event of a server failure which
requires restart of the server.
2. Goals and Requirements
There are several levels of goals for this protocol. There are a set
of requirements with which it must comply, and then there are a set
of goals for the protocol and the way that it is used that are listed
in priority order.
2.1. Requirements on this Protocol
The following list of requirements must be (and are) achieved by this
protocol.
1. Implementations of this protocol work with existing DHCP client
implementations based on the DHCP protocol [1]. It must work
with today's clients!
2. Implementation works with existing BOOTP relay implementations.
3. Can be specified with sufficient clarity that unique implementa-
tions will work well together the first time (e.g. DHCP today
largely meets this requirement).
4. Work well with minimum of two and a maximum of 16 servers.
2.2. Goals of this Protocol
The following are the goals of this protocol. These goals are listed
in priority order. The protocol meets all of these goals.
1. Avoid binding an IP address to a client while that binding is
currently valid for another client. In other words, don't allo-
cate the same IP address to two clients.
2. Ensure that an existing client can keep its existing IP address
binding if it can communicate with any DHCP server using this
protocol -- not just the server that originally offered it the
binding.
DISCUSSION:
Kinnear, Cole & Droms [Page 6]
DRAFT July 1997
There is a subtle but very important point here. For exam-
ple, assume that there are five servers using this protocol.
Everything is running fine, and then the network becomes par-
titioned, and three servers can communicate among themselves,
and the other two can communicate among themselves -- but the
set of three cannot communicate with the set of two. Each
set, however, can communicate with some clients.
In this situation, every client that can communicate with a
DHCP server in either set should be able to continue to use
its existing binding, even if the server that originally cre-
ated the binding is not included in the set of servers with
which it can communicate.
3. Do not add any requirement for communication with another server
to the processing between a DHCPDISCOVER and a DHCPOFFER or
between a DHCPREQUEST and a DHCPACK.
DISCUSSION:
This is another subtle point. The implications of this goal
are that "lazy" update of IP address binding information is
required. In other words, because of this goal, the protocol
cannot require one server to update another server with
information concerning a new IP address binding prior to
sending the DHCPACK to the DHCP client.
As a result of this goal, a server may fail immediately after
sending the DHCPACK to the client but prior to successfully
sending a record of that information to any other server.
Should this happen, the DHCP client is the only operational
machine with a record of this binding -- and the protocol must
be (and has been) designed to properly deal with this situation.
3. Ensure that a new client can get an IP address from some server.
4. If a server goes down, and an external agent determines that it
is actually down as opposed to running but simply unable to com-
municate with other servers, then the addresses that it cur-
rently owns but are not yet bound may be recovered for use by
other servers.
5. Ensure that in the face of partition, where servers continue to
run but cannot communicate with each other, the above goals and
requirements are met. In addition, when the partition condition
is removed, allow graceful automatic re-integration without
requiring human intervention.
Kinnear, Cole & Droms [Page 7]
DRAFT July 1997
2.3. Limitations of this Protocol
The following are explicit limitations of this protocol. This is not
to say that they are not useful capabilities to have (that's why they
are explicitly listed, so that it will be clear that this protocol
does not supply them).
1. Determination of permanent server failure.
The protocol provides a way to propagate information about the
permanent failure of a server, but no way to detect a permanent
failure. Transient failures are detected, but there is no mech-
anism in this protocol to determine when a transient failure is
really a permanent failure. Some external agent must make this
determination -- and must ensure that the server declared perma-
nently failed is not simply partitioned from the other servers
and unable to communicate with them. The server which has been
declared permanently failed by the external agent MUST be
informed of that declaration prior to restart.
DISCUSSION:
The existing configuration messages allow one server to
declare another server as permanently failed and remove it
from the group. That is not the issue. What makes fully
automatic determination of permanent server failure impracti-
cal is distinguishing between permanent server failure (which
is easily defined as transient server failure that has gone
on too long) and partition of the group of servers.
Once communication fails with a server, the other servers
cannot know if it is still operating or not, and removing an
operating server from the group is an activity fraught with
peril.
This protocol is designed so that a server which is parti-
tioned from the group will re-integrate cleanly when it can
communicate again with the rest of the group.
Group membership protocols typically handle a partition situ-
ation (when they bother to handle it at all) by having the
partitioned server determine that it has been partitioned and
shut itself down. It detects a partition condition in one of
two ways: either it can't communicate with the "master", or
it can't communicate with the "majority" of the group. In
either case, it shuts down.
We believe that this is not an appropriate response for a
Kinnear, Cole & Droms [Page 8]
DRAFT July 1997
DHCP server. If my DHCP client can talk to a DHCP server, I
want my client to continue to operate -- I'm not interested
in having the only DHCP server to which I can talk shut
itself down!
2. Some addresses are temporarily unavailable during transient
server failure.
The full range of existing IP addresses that are potentially
available for allocation is reduced during the period of a tran-
sient server failure. The size of the pool of addresses that
are available for allocation but not yet allocated SHOULD be
configurable for each server. If the server is subsequently
declared to have undergone a permanent failure, these addresses
will be made available again.
Note that it is only the addresses not yet allocated but avail-
able for allocation that are unusable during the period of a
transient server failure. IP addresses that have been allocated
to clients may continue to be used by those clients even during
server failure. Indeed -- to allow existing clients to be able
to renew their existing IP addresses even if the server who
granted them the lease has failed is a primary reason why this
protocol exists.
2.4. Failures
This section makes explicit both classes of failures as well as a
list of specific failure scenarios in order to facilitate discussion
of the capabilities of this protocol.
o "transient server failure"
A transient server failure is one where a server is unable to
respond to requests, but later becomes operational and able to
respond to requests. Its local stable storage (i.e., whatever
mechanism it uses to preserve its binding information) is accu-
rate as of the time that transient server failure began.
o "permanent server failure"
A permanent server failure is one where a server is unable to
respond to requests -- probably for an extended period. While the
protocol defined in this document supports declaration of a per-
manent server failure, the decision that a transient server fail-
ure is in reality a permanent server failure is beyond the scope
of this protocol.
Kinnear, Cole & Droms [Page 9]
DRAFT July 1997
This determination will be likely be performed by some adminis-
trative entity, although in the future a group membership proto-
col could be integrated with the protocol defined in this docu-
ment to make such determinations automatically.
o "partition"
A network partition is caused by a failure of the underlying com-
munications substrate, such that two systems that could previ-
ously communicate cannot now do so. This may mimic transient
server failure, but is not the same because in this case the
server that appears to have failed may still be operational and
interacting with clients.
There is a form of partition known as "partial partition", where
the transitivity of communication usually expected is not
achieved. Imagine a set of servers organized (for the purposes
of exposition only) as a ring where each server can communicate
with its neighbors, but nobody else -- and when the number of
servers is greater than three, a partial partition situation
exists.
This term may also be used as a noun, as in "each partition may
communicate with ...", and in this case it refers to the group of
servers which can communicate normally (as distinguished from
those with which that group cannot communicate).
o "communication failure"
Communications failure describes the condition where the communi-
cation channel between two servers becomes impossible. "Partial
communication failure" describes the case where the normally
bidirectional communications channel becomes unidirectional,
where one server can send to but not receive from another server.
Some examples of the above failures are given below:
1. A single server crashes and reboots. [transient failure]
2. A single server crashes and stays down for a period of hours and
then reboots (either automatically or through some external
agent). [transient failure]
3. A single server fails and never returns. No permanent failure
is declared for this server. [transient failure]
4. A single server fails. A permanent failure is declared for this
server. [permanent failure]
Kinnear, Cole & Droms [Page 10]
DRAFT July 1997
5. A group of two servers are partitioned so that they cannot com-
municate, but each can communicate to some clients. [partition]
6. A group of five servers are partitioned so that three can commu-
nicate together and the remaining two can also communicate, but
the two partitions cannot communicate. Each partition can com-
municate with a subset of the clients, and these subsets are
disjoint. [partition]
7. A group of five servers are partitioned so that three can commu-
nicate together and the remaining two can also communicate, but
the two partitions cannot communicate. Each server continues to
be able to communicate with all of the clients. [partition]
DISCUSSION:
This situation is unlikely to occur, but the protocol should
be able to handle it.
8. Server A can send packets to server B, but cannot receive pack-
ets from server B. [partial communications failure]
9. There are four servers, A, B, C, and D. A cannot communicate
with C, B cannot communicate with D. [partial partition]
DISCUSSION:
This section on failures may well not belong in the final docu-
ment. For the purposes of review of the rest of the protocol,
however, defining a common language to describe failures and giv-
ing specific examples of failures as an aid to discussion seemed
useful.
3. Overview
At the most basic level, the DHCP protocol specifies the behavior of
DHCP servers which communicate with DHCP clients in order to allocate
IP address to the clients as well as provide a variety of configura-
tion parameters information to them. It is the allocation of IP
addresses to clients by the server that creates a requirement to
update what is known as "stable storage" -- typically held on disk.
This information is used to "remember" the IP address bindings that
have been made by the DHCP server in order to avoid allocating the
same IP address to two clients.
The key motivation for an inter-server protocol is the desire to
allow a client to continue to use its IP address (i.e., be able to
Kinnear, Cole & Droms [Page 11]
DRAFT July 1997
renew its lease on an IP address) even if the server who initially
offered it the lease on its IP address is unavailable for some rea-
son. In addition, no IP address should ever be bound to two clients
simultaneously.
Providing multiple DHCP servers to which each client can communicate
is the first step in creating this reliable DHCP capability.
In addition, these DHCP servers must communicate among themselves in
order to provide this reliable DHCP capability.
3.1. Information Communicated by the Protocol
There are three types of information which must be communicated
between servers implementing the server server protocol.
o Client Binding Information
This entire interserver protocol exists in order to allow servers
to share information about client bindings of IP addresses.
Servers must be able to update other servers about client bind-
ings that they have created, and must be able to receive similar
updates from other servers about client bindings that the other
servers have made or changed.
o Address Management Information
In order to implement an effective strategy for client binding
information updates, this protocol defines some additional states
for an IP address beyond those defined or implied by RFC 2131 [1]
that are not directly connected with client binding information.
The servers need to communicate among themselves concerning these
states, and this communication is enabled by the address manage-
ment information portion of the protocol.
o Group Management Information
While it is possible to conceive of a group of servers statically
configured to be part of a server group, the operational charac-
teristics of such an approach are far from pleasant. The group
management portion of this protocol allows a server to determine
the groups to which another server belongs; determine for each
group the current membership in the group; determine for each
group the subnets and IP addresses managed by that group; and
join or leave a server group.
Kinnear, Cole & Droms [Page 12]
DRAFT July 1997
3.2. Server Groups
Fundamental to this protocol is the "group" of servers which are com-
municating and with which the clients can communicate in order to
provide a reliable DHCP service.
Each server group (SG) to which a server belongs is associated with a
particular set of address pools. These address pools are those which
exist on a single network segment (sometimes called a single "wire").
An active server can be (and typically would be) a member of several
groups simultaneously. This protocol allows a server to join an
existing SG. Which SGs a server would join is a configuration issue
for a particular server, and outside of the realm of this protocol --
although considerable support is provided in order to make this a
solvable problem.
The membership of a particular SG will change over time, and in order
to ensure that each server is made aware of any changes in group mem-
bership in a timely way, every protocol message which is sent in the
inter-server protocol includes a group generation number (with a few
exceptions).
Whenever a message is received, the group management layer of the
software MUST verify that the group generation number matches the
current group generation number for that SG stored in the server. If
there is a mismatch, the group management layer will discard the mes-
sage. It will then attempt to update its knowledge of the current
group (and incidentally bring its generation number up to date in the
process).
In this way, any changes in group membership become spread throughout
the group as fast as possible -- and no messages that are out of syn-
chronization with the latest concept of group membership can be
received.
A server attempts to become a member of a particular group by using
the configuration messages described in Section 7 below. In addi-
tion, a server can remove another server from the group using these
messages -- but in this case an external agent must ensure that the
server being removed is truly inactive and not just partitioned.
3.3. Messages and Operations Defined by the Protocol
The protocol requires that servers who implement it can communicate,
each with the other, in a point-to-point manner (when all are operat-
ing correctly). It allows for the possibility that they can fail
Kinnear, Cole & Droms [Page 13]
DRAFT July 1997
entirely (i.e., crash) or be unable to communicate with each other
for a variety of reasons.
Each server will periodically need to communicate with other servers
in the group. There are several recurring styles of communication
that, if defined, will assist in explaining the major concepts of
this protocol. These major styles of group communication are as fol-
lows:
There are "messages", which for the purpose of this specification
consist of a communication between two servers. Messages are gath-
ered into higher level generic "operations", which describe the form
of the operation, and are made up of messages communicated between
more than one server. These generic operations are then instantiated
into specific operations as part of the various portions of the pro-
tocol.
3.3.1. Generic Protocol Messages
Messages are used to communicate between a pair of servers.
o QUERY
A QUERY operation is performed when one server wishes to obtain
knowledge about the server cache of another server.
o UPDATE
An UPDATE operation is performed when one server wishes to update
the information in the cache of another server.
3.3.2. Generic Protocol Operations
These generic protocol operations are used when a server must commu-
nicate with more than one other server.
o POLL
A POLL operation is used when one server must contact every other
server in the group using a QUERY message in order to request
that they respond with some information (typically concerning an
IP address). Usually, if the server executing the POLL cannot
contact all of the other servers using the QUERY message, it will
use whatever information it could glean from those it could con-
tact.
o COMPLETE POLL
Kinnear, Cole & Droms [Page 14]
DRAFT July 1997
A COMPLETE POLL is like a POLL in that one server attempts to
contact every other server using a QUERY message -- but in a COM-
PLETE POLL it must successfully complete a QUERY with each of
them or the operation itself fails to complete.
o PUSH
A PUSH operation is used when one server wants to update all of
the other servers using an UPDATE message. In a way similar to
the POLL operation, a PUSH operation will succeed if the server
employing it has managed to contact at least one other server in
the group with a successful UPDATE.
o COMPLETE PUSH
A COMPLETE PUSH is analogous to a COMPLETE POLL -- the COMPLETE
PUSH operation requires the server to attempt to UPDATE every
other server in the group. If every server responds successfully
to the UPDATE, the COMPLETE PUSH succeeds, otherwise the COMPLETE
PUSH fails.
Note that both PUSH and POLL involve operations to all of the servers
in the group.
3.3.3. Specific Protocol Operations
These above generic forms of inter-server communication are utilized
in the following ways in the Client Binding and Address Management.
Client Binding Management:
o CLIENT BINDING POLL (operation)
This operation involves one server asking every other server
using a QUERY for client binding information concerning a partic-
ular IP address. If all of the other servers are not opera-
tional, the requesting server will use any information it
receives.
o CLIENT BINDING COMPLETE PUSH (operation)
This operation involves one server informing all of the other
servers using an UPDATE about updated client binding information.
While there is utility in reaching even one other server (in some
cases) the operation is not deemed to have succeeded unless all
of the other servers were successfully updated with the new
information.
Kinnear, Cole & Droms [Page 15]
DRAFT July 1997
Address Management:
o UNBINDABLE COMPLETE POLL (operation)
In this operation, all of the other servers are contacted using a
QUERY concerning one (or more) IP addresses, and they all report
on whether that IP address(es) is UNBINDABLE or not. This opera-
tion fails if any server fails to respond to the QUERY or if any
server responds to the QUERY with a negative answer (i.e., the IP
address is not currently UNBINDABLE). It succeeds only when all
of the servers in the server group answer that the address is
UNBINDABLE.
o TRANSFER (message)
This message is used to transfer BINDABLE IP addresses from one
server to another (used when the SG is partitioned and the normal
UNBINDABLE COMPLETE POLL cannot be used to make an IP address
BINDABLE, but also when all of the UNBINDABLE IP addresses have
already been made BINDABLE by some server).
The information is sent from the initiating to the responding
server as a QUERY and includes the subnet specification and the
number of BINDABLE IP addresses the initiating server has avail-
able for that address pool, and the number of BINDABLE IP
addresses it is requesting.
The responding server is free to give the initiating server all,
some, or none of the number of IP addresses the initiating server
has requested.
3.4. IP Address State
The concept of the state of an IP address is largely implicit in the
DHCP RFC [1]. However, in order to manage pools of IP addresses with
multiple servers, the states and transitions between them must be
made quite explicit.
3.4.1. IP Address State: Basic DHCP Protocol
When an IP address is always controlled by a single DHCP server
(implicit in the definition of DHCP in the current DHCP draft [1])
the IP address is either in the BINDABLE state or the BOUND state.
The following state diagram represents the states that an IP address
may occupy based on the current DHCP draft. (Note that these terms
do not appear in [1], but are terms that describe concepts that are
Kinnear, Cole & Droms [Page 16]
DRAFT July 1997
implicit in the RFC.)
+-----------------+
| |
| BINDABLE |<--+
| | |
+-----------------+ |
| |
V |
+-----------------+ |
| | |
| BOUND |---+
| |
+-----------------+
Figure 3.4.1-1: Basic DHCP IP address state transition diagram
When an IP address transitions from BINDABLE to BOUND, that transi-
tion must be recorded in the server's stable storage prior to the
transition being "published" to any observer outside of the server.
3.4.2. IP Address State: Extensions to Support the Interserver Protocol
The situation is more complex when multiple servers are managing the
same set of IP addresses as required by this protocol. Three new
states are defined for an IP address: UNBINDABLE, POLLING, PUSHED and
EXPIRED.
This is the state diagram for IP address state required by this pro-
tocol:
Kinnear, Cole & Droms [Page 17]
DRAFT July 1997
+-----------------+
| |
| UNBINDABLE |<--------+
| | |
+-----------------+ |
| |
V |
+-----------------+ |
| | |
| POLLING |-------->|
| | |
+-----------------+ |
| |
V |
+-----------------+ |
| | |
| BINDABLE |-------->|
| | |
+-----------------+ |
| |
----------------------------- |
V |
+-----------------+ |
| | |
+-->| BOUND |-------->|
| | | |
| +-----------------+ |
| | | |
| | V |
| | +-----------------+ |
| | | | |
| | | PUSHED |-->|
| | | | |
| | +-----------------+ |
| | | |
| V V |
| +-----------------+ |
| | | |
+<--| EXPIRED |-------->+
| |
+-----------------+
Figure 3.4.2-1: Extended DHCP IP address state transition diagram
required for the Inter-server protocol.
Kinnear, Cole & Droms [Page 18]
DRAFT July 1997
For every server which cooperates using this protocol, an IP address
is in one of the following six states:
o UNBINDABLE
This state represents the default state for every IP address.
Explicit action must be taken to move an IP address from this
state into the BINDABLE state. An UNBINDABLE COMPLETE POLL must
be performed and must complete successfully.
Any IP address that has previously been BOUND must retain infor-
mation concerning the server that PUSHED the binding information,
the client to which it was bound, and the lease time for the
binding. This information is used when a server is removed from
the server group.
o POLLING
While an UNBINDABLE COMPLETE POLL operation is being performed,
an IP address is in the POLLING state. This ensures that if two
servers are simultaneously performing an UNBINDABLE COMPLETE POLL
operation that involves the same address that neither of them
will succeed in making that address BINDABLE.
o BINDABLE
In this state, the IP address is available to be offered to a
DHCP client, and if the client accepts the offer, it may be bound
to that client.
An IP address is only BINDABLE by a single server at a time. A
server must know for precisely which IP addresses it has on its
list of BINDABLE addresses. A server does not know about any
other server's list of BINDABLE addresses. (Although performance
optimizations are possible where a server may develop hints about
this information, they are not required).
An IP address can move from the BINDABLE state into the BOUND
state through the normal activity of the DHCP protocol where a
server interacts with a client. When this happens, the Client
Binding Management portion of the protocol is used to inform
other servers of the change.
A server can also transfer ownership of a BINDABLE IP address to
another server upon request from that other server (and without
any interaction beyond that with the other server).
Kinnear, Cole & Droms [Page 19]
DRAFT July 1997
o BOUND
An address that is BOUND is associated with a particular DHCP
client, and usually is in use by that client (although it may
have abandoned the lease on that IP address). It may be termed
BOUND to that client. In the BOUND state the information about
the client binding has not been propagated to all of the other
servers in the server group.
o PUSHED
An address that is PUSHED is associated with a client in the same
was as a BOUND address. However, an address in the PUSHED state
indicates that all of the other servers in the server group have
been informed of the existence of the binding to this client.
When a DHCP client releases a lease on an IP address it moves
from either the BOUND or PUSHED state into the UNBINDABLE state,
but no explicit PUSH operation is required.
When the lease time and any grace period implemented by a server
both expire, then an IP address moves into the EXPIRED state.
Note that only a server that actually completes a CLIENT BINDING
COMPLETE PUSH will place its IP address into the PUSHED state.
The servers who receive the CLIENT BINDING COMPLETE PUSH will
place their IP addresses into the BOUND state.
DISCUSSION:
Many DHCP servers implement something called a "grace
period", which is a period after the the lease on a binding
expires that an IP address will not be offered to another
DHCP client. A lease which is in this "grace period" is
still BOUND or PUSHED as far as the inter-server protocol is
concerned.
o EXPIRED
An IP address is EXPIRED when it was BOUND and the term of the
lease (and any implemented grace period) has run out. It may be
termed EXPIRED to that client.
An EXPIRED IP address will transition to the UNBINDABLE state
when the server who shows it as EXPIRED receives an UNBINDABLE
COMPLETE POLL. It will respond to the UNBINDABLE COMPLETE POLL
after making the IP address UNBINDABLE.
Kinnear, Cole & Droms [Page 20]
DRAFT July 1997
It may be moved back into the BOUND state by an REQUEST/INIT-
REBOOT request from the previously bound client.
Note that an IP address can never go from BOUND to one client to
BOUND to another client without first passing through the UNBINDABLE
state. The line across the middle of the state transition diagram
helps to illustrate this.
Further, note that the transition from POLLING to BINDABLE requires
the successful completion of an UNBINDABLE COMPLETE POLL.
3.5. Overview of Server Operation
This section will give a brief sketch of the of the core elements of
the Client Binding Management and Address Management parts of the
protocol (from the perspective of an already configured group of
servers). Many of the possible cases are not described here, and
this section is not to be considered definitive. The definitive
description of this information is contained in Section 6 and in the
case of conflicts with information found there, the information in
Section 6 will govern.
3.5.1. DISCOVER
Prior to the receipt of a DISCOVER message, each server should have
built up a list of BINDABLE IP addresses -- for two reasons. First,
because an UNBINDABLE COMPLETE POLL is required to move an IP address
into the BINDABLE state, and an UNBINDABLE COMPLETE POLL may not be
possible due to server failure at any given instant. Second, because
even if an UNBINDABLE COMPLETE POLL was possible it would generally
take too long to do between a DISCOVER and an OFFER message.
A server should offer a BINDABLE address to a client upon receipt of
a DISCOVER message.
There are no inter-server protocol activities required when a DIS-
COVER is processed and an OFFER is returned to the client (assuming
of course that a BINDABLE address was available to be offered).
3.5.2. REQUEST/SELECTING
When a client accepts an offer by sending a SELECTING message, then
the server updates its stable storage with the binding information
and ACKs the client. It must then perform a CLIENT BINDING COMPLETE
PUSH operation to push the binding information to all of the other
Kinnear, Cole & Droms [Page 21]
DRAFT July 1997
servers (to which it can communicate at that time). There are some
limitations on the lease time that can be offered to the client until
at least one successful CLIENT BINDING COMPLETE PUSH has succeeded
for the offering server. See Section 4.4.1 for additional details.
3.5.3. REQUEST/INIT-REBOOT
In the usual case where the server who created the binding for the
requesting client managed to PUSH that information to the other
servers using a CLIENT BINDING COMPLETE PUSH, the receiving server
will have the binding information for this client. If this informa-
tion can be verified, then ACK the client -- else NAK it.
If the IP address was in the EXPIRED state, then move the IP address
to the PUSHED state.
3.5.4. REQUEST/RENEWING
Upon receipt of a RENEWAL message (which is unicast from the client
to the server), it is expected that the server will have accurate
information concerning the binding of the client. If it does not,
process the message like a REBINDING, below. Given that the server
has information sufficient to extend the lease, it should update its
stable storage with the lease extension, and then ACK the client with
the extended time. Then it must perform a CLIENT BINDING COMPLETE
PUSH operation to the other servers with the updated binding informa-
tion.
3.5.5. REQUEST/REBINDING
Upon receipt of a REBINDING message (which is broadcast from the
client), the server will check to see if it has any information about
the binding for this client. There are several possible cases:
1. Current information shows that this client owns the IP address.
Extend the lease, update stable storage, ACK the client, and
perform a CLIENT BINDING COMPLETE PUSH with the information to
the other servers.
2. Current information shows that some other client is BOUND to
this IP address.
This is a problem. Make the IP address UNAVAILABLE (see Section
12 for details).
Kinnear, Cole & Droms [Page 22]
DRAFT July 1997
3. Current information says this IP address is UNBINDABLE.
In this case, a server has probably created a binding and then
failed to propagate the information to this server. Perform a
POLL operation to see if any communicating server has any better
information.
If information is returned, then move to the appropriate case in
this list.
If no information is returned, then extend the lease on the IP
address, update stable storage, ACK the client, and PUSH the
information to the other servers.
3.5.6. RELEASE
When a release is received, if the client matches the binding infor-
mation in the server, then update stable storage with the release,
set the IP address UNBINDABLE, and perform a CLIENT BINDING COMPLETE
PUSH to inform other servers.
If the CLIENT BINDING COMPLETE PUSH operation fails due to inability
of an UPDATE message to succeed to another server, do nothing.
3.5.7. Expiration
When a lease on an IP address expires, move the lease to the EXPIRED
state and update stable storage with this information. From now on,
if some server performs an UNBINDABLE COMPLETE POLL operation to
gather information about this IP address, make the IP address UNBIND-
ABLE, update stable storage, and respond with the state of the IP
address as UNBINDABLE.
3.6. When a server is down or partitioned and can't be contacted
When a server is down or partitioned (i.e., can't be reached), then
some aspects of the normal DHCP client processing are different.
This section summarizes those differences:
o Client lease times for new clients will never be greater than
MAXIMUM_UNPUSHED_LEASE_TIME, since a CLIENT BINDING COMPLETE PUSH
cannot succeed.
o No UNBINDABLE COMPLETE PUSH will succeed, and thus no server will
be able to transition an address from the UNBINDABLE state into
Kinnear, Cole & Droms [Page 23]
DRAFT July 1997
the BINDABLE state. If a server runs low on addresses, it will
have to use TRANSFER messages to acquire new addresses from other
servers.
4. Client Binding Management
Client binding management is the aspect of the protocol which is con-
cerned with communicating information about client bindings from one
server to another. It is the core of the inter-server protocol.
The following messages and operations are used explicitly by a server
participating in the interserver protocol when DHCP client requests
and events require it, and are used implicitly by the SCSP cache
alignment procedure whenever a server (re)establishes communication
with another server.
4.1. Client Binding Messages
o CLIENT BINDING UPDATE
Update a single server with client binding information. This
operation will not complete successfully unless and until that
server is updated with the information being sent.
o CLIENT BINDING QUERY
Query a single server for its client binding information.
4.2. Client Binding Operations
The operations defined in for client binding management are:
o CLIENT BINDING COMPLETE PUSH
This operation involves one server using the UPDATE message to
inform all of the other servers about updated client binding
information. While there is utility in reaching even one other
server (in some cases) the operation is not deemed to have suc-
ceeded unless all of the other servers were successfully updated
with the new information.
o CLIENT BINDING POLL
This operation involves one server using the QUERY message to
inquire of every other server about client binding information
concerning a particular IP address. If all of the other servers
Kinnear, Cole & Droms [Page 24]
DRAFT July 1997
are not operational, the requesting server will use any informa-
tion it receives.
4.3. Client Binding Information
When binding data is sent as part of message concerned with client
binding management it contains the following information:
o IP Address
o Expiration [expressed as a delta seconds from the current time]
o Client ID
o MAC Address [including the hardware type]
o Last Transaction [selected from the list below]
o Last Transaction Time [expressed as a delta seconds from the cur-
rent time]
o Last Transaction Server [an IP address]
Each server must maintain as part of the binding information the
"last transaction time", the "last transaction", and the "last trans-
action server" associated with that binding.
The last transaction time is the time at which the binding changed in
response to a request (the last transaction) from the client. The
last transaction time is returned in an address information message
as a number of seconds from "now".
The possible last transactions are listed below. This list is
ordered by the precedence of the transactions and is used to help
determine if a response to an address information message contains
more recent information than that currently held by a server.
The last transaction is one of the following:
o DHCPREQUEST/SELECTING
o DHCPREQUEST/REBINDING
o DHCPREQUEST/INIT-REBOOT
o DHCPREQUEST/RENEWING
Kinnear, Cole & Droms [Page 25]
DRAFT July 1997
o DHCPRELEASE
o EXPIRATION
The IP address state information is transmitted as well, and it con-
sists of one of the following states:
o UNBINDABLE
o POLLING
o BINDABLE
o BOUND
o PUSHED
o EXPIRED
4.4. Initiating Client Binding Operations and Messages
4.4.1. CLIENT BINDING COMPLETE PUSH
The CLIENT BINDING COMPLETE PUSH operation is initiated whenever the
state of a server's client binding cache is changed, typically by the
receipt of a DHCP client request or expiration of a lease.
The lease time that is offered to a DHCP client must not be greater
than the MAXIMUM-UNPUSHED-LEASE-TIME for that SG until at least one
CLIENT BINDING COMPLETE PUSH has succeeded for that client binding.
Thus, as long as the state of the IP address is BOUND, then the
client should be offered the MAXIMUM-UNPUSHED-LEASE-TIME.
The lease time that is sent to the other servers in the CLIENT BIND-
ING COMPLETE PUSH is the lease time that the server would like to
give to the DHCP client, and once a CLIENT BINDING COMPLETE PUSH has
succeeded with that lease time in it (and the IP address state is set
to PUSHED), then the server is free to actually extend the client's
lease on the IP address with that lease time.
The servers which receive the CLIENT BINDING COMPLETE PUSH will place
their IP addresses into the BOUND state, not the PUSHED state.
Kinnear, Cole & Droms [Page 26]
DRAFT July 1997
4.4.2. CLIENT BINDING POLL
The CLIENT BINDING POLL is used when the server has received a DHCP
client request but believes that it has insufficient or out-of-date
information concerning this client's binding. Thus, the CLIENT BIND-
ING POLL is an attempt to gather more recent and up-to-date informa-
tion from the other servers in the SG.
DISCUSSION:
Is this really necessary? Given that SCSP will "align" the
caches of the servers at every reconnect, then what is the
value of asking "again"?
4.4.3. CLIENT BINDING UPDATE
The CLIENT BINDING UPDATE is initiated in three ways.
It is initiated at the client binding management level as the under-
lying operation in a CLIENT BINDING COMPLETE PUSH. It is initiated
at the client binding management level when a server realizes that
the server who returned information as a result of a CLIENT BINDING
QUERY returned information which was less up-to-date than that avail-
able to the current server. It is initiated at the SCSP level as
part of the cache state alignment process.
4.5. Responding to Client Binding Messages
When a server receives the following client binding messages, it
should respond as detailed below. Note that operations consist of
multiple messages at the initiator, but that when processing incoming
requests, only individual messages are evident.
4.5.1. CLIENT BINDING QUERY
The proper response to a CLIENT BINDING QUERY is to respond with the
current information in the client binding cache.
4.5.2. CLIENT BINDING UPDATE
The proper response to a CLIENT BINDING UPDATE is to determine if the
information received is more current than that available in the
server's cache. If it is not, then respond negatively to this
request. If it is, then update the client binding cache, ensure that
Kinnear, Cole & Droms [Page 27]
DRAFT July 1997
the changes have been written to stable storage, and respond success-
fully. Note that no CLIENT BINDING UPDATE should generate additional
client binding message activity (i.e., the CLIENT BINDING UPDATE
should not generate a CLIENT BINDING COMPLETE PUSH).
When a CLIENT BINDING UPDATE is received, the IP address should be
placed into the BOUND state, not the PUSHED state. Only the actual
server performing the CLIENT BINDING COMPLETE PUSH will place its IP
address into the PUSHED state.
5. Address Managment
Address management is the aspect of the protocol concerned with man-
aging the state of IP addresses that are not currently bound to any
client. It is a necessary part of the protocol in order to support
certain goals in the client binding management part of the protocol,
principally that of allowing a server to continue to operate even
though it was partitioned from other servers in the server group.
5.1. Address Management Operations
o UNBINDABLE COMPLETE POLL
In this operation, all of the other servers are contacted using a
QUERY operation concerning one (or more) IP addresses, and they
all report on whether that IP address(es) is UNBINDABLE or not.
If they are UNBINDABLE, then the current information on that IP
address is also reported (as in a CLIENT BINDING POLL). In con-
trast to a CLIENT BINDING POLL, this operation fails if any
server cannot be contacted or if any server answers the QUERY
with a negative answer (i.e., the IP address is not currently
UNBINDABLE). It succeeds when all of the servers answer that the
address is UNBINDABLE.
There is a subtle interaction required with the group management
layer of the protocol. A successful UNBINDABLE COMPLETE POLL
must be inhibited in certain cases where a server has been
removed from a server group.
The case is question is that where a server is removed from a
server group by a different server. Immediately after this hap-
pens, all UNBINDABLE COMPLETE POLLS must fail for a period equal
to the MAXIMUM-UNPUSHED-LEASE-TIME. After that time passes, then
UNBINDABLE COMPLETE POLLS may operate as they normally do.
Kinnear, Cole & Droms [Page 28]
DRAFT July 1997
DISCUSSION:
This covers the situation where a server gives a lease to a
while both the client and server are partitioned. Then, the
server goes away completely. The client stays up, but remains
partitioned. Then, the dead server is removed by another
server from the server group. At this point, UNBINDABLE COM-
PLETE POLL operations could (except for the above restriction)
begin to complete successfully. However, the client that was
given a lease while partitioned along with the server that
died certainly has an address, and when the partition is
removed (just after the UNBINDABLE COMPLETE POLL operation
which declared its IP address now BINDABLE for some server),
there would be a very dangerous situation developing.
The solution is to only offer leases to clients of the MAXIMUM-
UNPUSHED-LEASE-TIME until the information concerning their client
binding reaches all of the other servers in the group. Once that
happens, then they can be offered the normal lease time.
Thus, whenever any server is removed from the group (where it
doesn't remove itself), then there is a possibility that it may
have offered leases to clients about which no other server would
have any record. In this case, the remaining servers must wait
the MAXIMUM-UNPUSHED-LEASE-TIME before being able to complete an
UNBINDABLE COMPLETE POLL and reuse the BINDABLE addresses that
the removed server was using.
5.2. Address Management Messages
The following messages are part of the address management portion of
the protocol.
o TRANSFER
This message is used to transfer BINDABLE IP addresses from one
server to another (especially when the SG is partitioned and the
normal UNBINDABLE COMPLETE POLL cannot be used to make an IP
address BINDABLE, but also when all of the UNBINDABLE IP
addresses have already been made BINDABLE by some server).
The information sent from the initiating to the responding server
includes the subnet specification and the number of BINDABLE IP
addresses the initiating server has available for that address
pool, and the number of BINDABLE IP addresses it is requesting.
Kinnear, Cole & Droms [Page 29]
DRAFT July 1997
The responding server is free to give the initiating server all,
some, or none of the number of IP addresses the initiating server
has requested.
o UNBINDABLE QUERY
The UNBINDABLE QUERY operation is the primitive query from which
the UNBINDABLE COMPLETE POLL is constructed. It is identical to
the CLIENT BINDING QUERY defined above in terms of the data
returned, although the actions taken when it is received are
slightly different.
5.3. Initiating Address Management Operations and Messages
o UNBINDABLE COMPLETE POLL (operation)
This operation is initiated when the server detects that it needs
to generate more BINDABLE IP addresses. It will initiate this
operation whenever the number of BINDABLE IP addresses drops
below a configurable threshold.
Prior to initiating this operation, the server must change the
state for each IP address that will be part of the UNBINDABLE
COMPLETE POLL from UNBINDABLE to POLLING, and commit this state
change to stable storage.
DISCUSSION:
Is the commit to stable storage really necessary? Given that
we will abandon the POLL if we reboot (presumably), what is
the value of remembering that we were doing it?
For every IP address for which the UNBINDABLE COMPLETE POLL oper-
ation fails (i.e., some server responds in such a way that indi-
cates that the IP address is not UNBINDABLE, or some server fails
to respond at all), the IP address' state should be reset to
UNBINDABLE.
o TRANSFER (message)
The TRANSFER message, which attempts to transfer some IP
addresses from some other server to the initiating server, is
initiated whenever the number of BINDABLE IP addresses in an
address pool falls below a configurable threshold.
Kinnear, Cole & Droms [Page 30]
DRAFT July 1997
5.4. Responding to Address Management Messages
o TRANSFER
When receiving a TRANSFER message, the responding server inspects
its list of BINDABLE addresses for the address pool to which the
TRANSFER operation refers. It will attempt to offer the initiat-
ing server as many addresses as it requested, with the limitation
that it will never give away more than half of its pool of BIND-
ABLE addresses in any one request.
o UNBINDABLE QUERY
The responding server will respond to this query just like it
responds to a CLIENT BINDING QUERY as far as the information com-
municated to the initiating server is concerned.
In addition, if the IP address mentioned in this query was in the
EXPIRED state, prior to responding to this message, the respond-
ing server will move that IP address to the UNBINDABLE state,
commit this change to stable storage, and then respond with
information that indicates the IP address in question was UNBIND-
ABLE.
Note that an UNBINDABLE QUERY will not be generated to any server
if at least one server in the SG is currently not able to be con-
tacted, as known by the SCSP "Hello" subprotocol. This will pre-
vent unnecessary transitions from the EXPIRED to the UNBINDABLE
state when an UNBINDABLE COMPLETE POLL would not be able to com-
plete in any case.
6. Actions in Response to DHCP Client Messages and Events
This section defines the actions that should be taken in the client
binding and address management portions of the protocol when incoming
DHCP requests (messages) are received.
DISCUSSION:
There is considerable commonality in the sections that describe
the various DHCP client messages below. Once the details have
stabilized, it should be possible to compress the explanations.
Kinnear, Cole & Droms [Page 31]
DRAFT July 1997
6.1. DISCOVER
Prior to the receipt of a DISCOVER message, each server should have
built of a list of BINDABLE IP addresses -- for two reasons. First,
because a CLIENT BINDING COMPLETE POLL is required to get a BINDABLE
IP address, and a CLIENT BINDING COMPLETE POLL may not be possible
due to server failure at any given instant. Second, because even if
a CLIENT BINDING COMPLETE POLL were possible, it would be unwise to
require such an operation between a receipt of a DISCOVER message and
the response of an OFFER to a client.
There are several cases involved in processing a DISCOVER request,
depending on the state of the requested IP address in the DISCOVER
request:
o No specific IP address requested.
Offer a BINDABLE address to the client. Record that this address
was offered in the cache memory of the server, but there is no
need to update the stable storage of the server with any informa-
tion. The IP address continues to be BINDABLE as far as the
inter-server protocol is concerned.
o Requested IP address is UNBINDABLE.
If the IP address is UNBINDABLE, then perform a UNBINDABLE COM-
PLETE POLL operation in an attempt to make the IP address BIND-
ABLE. If the operation is successful, then respond as though the
IP address were BINDABLE, below. If the results of the attempt
to make the IP address BINDABLE resulted in a discovery that the
IP address is now BOUND or PUSHED, then respond as for BOUND our
PUSHED, below. Otherwise (i.e., the IP address is BINDABLE for
some other server, or no an UNBINDABLE COMPLETE POLL was not pos-
sible) then respond as above for "No specific IP address
requested".
o Requested IP address is BINDABLE.
Offer the IP address to the client. IP address remains BINDABLE.
o Requested IP address is BOUND or EXPIRED.
If the IP address is BOUND or EXPIRED to the requesting client,
then set it to BOUND and offer it to the client -- with a lease
time of MAXIMUM-UNPUSHED-LEASE-TIME. Otherwise (i.e., the IP
address is BOUND or EXPIRED to some other client), respond as in
"No specific IP address requested", above.
Kinnear, Cole & Droms [Page 32]
DRAFT July 1997
o Requested IP address is PUSHED.
If the IP address is PUSHED to the requesting client, then offer
it to the client -- with a normal lease time. Otherwise (i.e.,
the IP address is PUSHED to some other client), respond as in "No
specific IP address requested", above.
6.2. REQUEST/SELECTING
The client uses a REQUEST/SELECTING to accept the offer of a lease
made by a server. When a server receives such a message, and where
the server-id option reflects the IP address of that server, then if
the IP address is in the following states the server should respond
in the following way:
o UNBINDABLE
If the IP address is UNBINDABLE, then perform a UNBINDABLE COM-
PLETE POLL operation in an attempt to make the IP address BIND-
ABLE. If that operation is successful, then respond as though
the IP address were BINDABLE, below. If the results of the
attempt to make the IP address BINDABLE resulted in a discovery
that the IP address is now BOUND, then respond as for BOUND,
below. Otherwise (i.e., the IP address is BINDABLE for some
other server, or no a complete POLL was not possible) NAK the
REQUEST.
o BINDABLE
If the IP address is BINDABLE and has been offered to the
requester, then bind the IP address to the client, set the IP
address BOUND, and update stable storage. Then, ACK the client,
and finally perform a PUSH operation of the binding information
to the other servers.
o BOUND or EXPIRED
If the IP address is BOUND or EXPIRED to the requesting client,
then set the state to BOUND, update the expiration time using the
normal lease time, update stable storage, ACK the client with the
MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
PLETE PUSH with the normal lease time.
If the IP address is BOUND or EXPIRED to a different client, then
NAK this REQUEST.
Kinnear, Cole & Droms [Page 33]
DRAFT July 1997
o PUSHED
If the IP address is PUSHED to the requesting client, set the IP
address to be PUSHED, update the expiration time, update stable
storage, and ACK the client. Finally, perform a CLIENT BINDING
COMPLETE PUSH operation of the updated binding information to the
other servers.
Use the normal lease time in all of the above operations.
If the IP address is PUSHED to some other client, then NAK the
request.
6.3. REQUEST/INIT-REBOOT
The client uses a REQUEST/INIT-REBOOT to query the server (as part of
the client boot process) to determine if a "remembered" binding is
still valid. If the requested IP address will be in one of the fol-
lowing states:
o UNBINDABLE
If the IP address is UNBINDABLE, then perform a UNBINDABLE COM-
PLETE POLL operation in an attempt to make the IP address BIND-
ABLE. If the operation is successful, then respond as though the
IP address were BINDABLE, below. If the results of the attempt
to make the IP address BINDABLE resulted in a discovery that the
IP address is now BOUND, then respond as for BOUND, below. Oth-
erwise (i.e., the IP address is BINDABLE for some other server,
or a complete POLL was not possible) NAK the REQUEST.
DISCUSSION:
This means that if a server creates a binding for a client and
fails to PUSH the information to any other server prior to
undergoing a server failure, and if the client is powered off
prior to the time when it will issue a REBINDING message, it
will not get back the same lease when it is powered back on.
The reasoning for this (and the difference from the REBINDING
case below) is that in this case the server has no way to
determine if the requested address in the INIT-REBOOT request
is current or perhaps very old indeed. In the REBINDING case
the client is currently using the address, so the client at
least believes that it is current and not in use by some other
client. In this case, however, no such assumption is possi-
ble.
Kinnear, Cole & Droms [Page 34]
DRAFT July 1997
In the case where a server which creates a binding fails prior to
PUSHing the information about a lease to some other server, and
the client which receives that binding makes a REBINDING request
prior to either failing or being shutdown, it will get back the
existing binding upon restart and INIT-REBOOT -- since the
REBINDING will have caused a recovery of the binding information
and that will have been distributed through a CLIENT BINDING COM-
PLETE PUSH.
o BINDABLE
If the IP address is BINDABLE, then bind the IP address to the
client, set the IP address BOUND, and update stable storage.
Then, ACK the client, and finally perform a PUSH operation of the
binding information to the other servers.
o BOUND or EXPIRED
If the IP address is BOUND or EXPIRED to the requesting client,
then set the state to BOUND, update the expiration time using the
normal lease time, update stable storage, ACK the client with the
MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
PLETE PUSH with the normal lease time.
If the IP address is BOUND or EXPIRED to a different client, then
NAK this REQUEST.
o PUSHED
If the IP address is PUSHED to the requesting client then set the
IP address PUSHED, update the expiration time, update stable
storage, and ACK the client. Finally, perform a CLIENT BINDING
COMPLETE PUSH operation of the updated binding information to the
other servers. Use the normal lease time for all of the above
operations.
If the IP address is PUSHED to some other client, then NAK the
request.
6.4. REQUEST/RENEWING
Upon receipt of a RENEWAL message (which is unicast from the client
to the server), it is expected that the server will have accurate
information concerning the binding of the client since this is the
server that the client believes most recently sent an ACK to the
client concerning this IP address binding.
Kinnear, Cole & Droms [Page 35]
DRAFT July 1997
Perform the following actions if the IP address being renewed (i.e.,
the IP address in ciaddr) is in one of these states:
o UNBINDABLE
If the IP address is UNBINDABLE, then perform an UNBINDABLE COM-
PLETE POLL operation in an attempt to make the IP address BIND-
ABLE. If the operation is successful, then respond as though the
IP address were BINDABLE, below. If the results of the attempt
to make the IP address BINDABLE resulted in a discovery that the
IP address is now BOUND, then respond as for BOUND, below.
If the IP address is determined to be BINDABLE for some other
server, then NAK the request, and set the IP address to be
UNAVAILABLE since this likely represents a duplicate allocation
of an IP address (see Section 11, Open Questions, for details).
Otherwise NAK the request.
o BINDABLE
If the IP address is BINDABLE, then bind the IP address to the
client, set the IP address BOUND, and update stable storage.
Then, ACK the client, and finally perform a PUSH operation of the
binding information to the other servers.
o BOUND or EXPIRED
If the IP address is BOUND or EXPIRED to the requesting client,
then set the state to BOUND, update the expiration time using the
normal lease time, update stable storage, ACK the client with the
MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
PLETE PUSH with the normal lease time.
If the IP address is BOUND or EXPIRED to a different client, then
NAK this REQUEST.
o PUSHED
If the IP address is PUSHED to the requesting client then set the
IP address PUSHED, update the expiration time, update stable
storage, and ACK the client. Finally, perform a CLIENT BINDING
COMPLETE PUSH operation of the updated binding information to the
other servers. Use the normal lease time for all of the above
operations.
If the IP address is PUSHED to some other client, then NAK the
request and set the IP address to UNAVAILABLE. (see Section 11,
Kinnear, Cole & Droms [Page 36]
DRAFT July 1997
Open Questions, for details).
6.5. REQUEST/REBINDING
Upon receipt of a REBINDING message (which is broadcast from the
client), the server will check to the state of the address requested
for rebinding (i.e., the ciaddr). There are several cases possible:
o UNBINDABLE
If the IP address is UNBINDABLE, then perform an UNBINDABLE COM-
PLETE POLL operation in an attempt to make the IP address BIND-
ABLE. If the operation is successful, then respond as though the
IP address were BINDABLE, below. If the results of the attempt
to make the IP address BINDABLE resulted in a discovery that the
IP address is now BOUND, then respond as for BOUND, below.
If the IP address is determined to be BINDABLE for some other
server, then NAK the request. Set the IP address to be UNAVAIL-
ABLE since this likely represents a duplicate allocation of an IP
address (see Section 11, Open Questions, for details).
If no information is returned from any server that this IP
address is anything but UNBINDABLE, then consider the address
BOUND to this client, and proceed as in BOUND below.
DISCUSSION:
This is one of the key points of the inter-server protocol.
In this case, a server has created a binding and then failed
prior to telling any other server about that binding. Eventu-
ally, the client to whom that binding was made will attempt a
REQUEST/REBINDING and contact a different server. That dif-
ferent server will be able to determine nothing about that IP
address. As far as can be determined, it is not BOUND to any
client, and it is not BINDABLE for any other server. In this
restricted case, the server will renew the lease for the
client and move the IP address into the BOUND state -- and
PUSH this information to the rest of the servers.
How can this be safe? Well, remember that the client is
presently using the IP address to make this request. In this
limited case where a server crashes before PUSHing information
about a BOUND IP address to any other server, the client to
whom the IP address is BOUND is the only running machine with
any record of that binding. In this case, the DHCP servers
will accept that client's information about the binding as
Kinnear, Cole & Droms [Page 37]
DRAFT July 1997
correct.
o BINDABLE
If the IP address is BINDABLE, then bind the IP address to the
client, set the IP address BOUND, and update stable storage.
Then, ACK the client, and finally perform a PUSH operation of the
binding information to the other servers.
o BOUND or EXPIRED
If the IP address is BOUND or EXPIRED to the requesting client,
then set the state to BOUND, update the expiration time using the
normal lease time, update stable storage, ACK the client with the
MAXIMUM-UNPUSHED-LEASE-TIME, and perform a CLIENT BINDING COM-
PLETE PUSH with the normal lease time.
If the IP address is BOUND or EXPIRED to a different client, then
NAK this REQUEST.
o PUSHED
If the IP address is PUSHED to the requesting client then set the
IP address PUSHED, update the expiration time, update stable
storage, and ACK the client. Finally, perform a CLIENT BINDING
COMPLETE PUSH operation of the updated binding information to the
other servers. Use the normal lease time for all of the above
operations.
If the IP address is PUSHED to some other client, then NAK the
request and set the IP address to UNAVAILABLE. (see Section 11,
Open Questions, for details).
6.6. RELEASE
When a RELEASE is received, an IP address will be in one of the fol-
lowing states:
o UNBINDABLE
If the IP address is UNBINDABLE, then perform a CLIENT BINDING
POLL operation in an attempt to determine if this IP address is
BOUND to any client.
If the results of the POLL operation indicate that the IP address
is now BOUND, then respond as for BOUND, below.
Kinnear, Cole & Droms [Page 38]
DRAFT July 1997
If the IP address is determined to be BINDABLE for some other
server, then NAK the request. Set the IP address to be UNAVAIL-
ABLE since this likely represents a duplicate allocation of an IP
address (see Section 11, Open Questions, for details).
Otherwise, ignore the RELEASE.
o BINDABLE
If the IP address is BINDABLE, ignore the RELEASE.
o BOUND, PUSHED, or EXPIRED
If the IP address is BOUND, PUSHED, or EXPIRED to the requesting
client set the IP address to be UNBINDABLE, update stable stor-
age, and perform a CLIENT BINDING COMPLETE PUSH to update the
other servers with this information.
6.7. Lease Period Expiration
When the lease period on a BOUND or PUSHED IP address expires, set
the IP address to be EXPIRED and update stable storage.
7. Group Management
The group management part of the protocol is concerned with configur-
ing a server into or out of a server group (SG). It allows discovery
of information concerning the configuration of an existing server
group as well as the address pools that are managed by a server
group. While it is possible to conceive of a statically defined
server group, the operational characteristics (both for group startup
as well as removal of a server from a group) are quite painful.
Group management messages are used add a server to a group as well as
to remove a server from a group. A server must add itself to a group
-- it cannot be added by another server. A server may be removed by
any server in the group, including itself.
In addition to changing the group membership, group management mes-
sages are used to keep the various servers up to date with respect to
the current membership of the group.
Once a server successfully become part of a group using the group
management messages, it the goes into the SCSP protocol. This proto-
col determines which servers in the SG are currently in communication
with this server, and starts an automatch "cache alignment" process
Kinnear, Cole & Droms [Page 39]
DRAFT July 1997
with each connected server.
7.1. Group Management Operations
o SG CHANGE
The SG CHANGE operation is a two-stage operation made up of a
propose and then a commit phase. It uses the SG PROPOSE CHANGE
and SG COMMIT CHANGE messages as part of this operation. It is
used to change the membership of the group, either to add a
server or to remove a server.
7.2. Group Management Messages
o SG DISCOVERY QUERY
The first stage of becoming a server participating in the inter-
server protocol is to determine the existing SG ID for each SG
for which participation in the inter-server protocol is desired.
Assuming that a server has been provided or can discover the IP
address of a server maybe in a group to which it wants to join, a
server who wants to become a member of a group will send a SG
DISCOVERY QUERY message to that server.
The reply to the SG DISCOVERY QUERY message is a message which
contains the list of SG identifiers for all of the groups to
which the replying server belongs. These SG ids can then be used
in SG CONFIGURATION messages to determine more information about
each SG.
This operation is performed only upon one server at a time, since
at this point there is no notion of a "current" server group.
o SG CONFIGURATION QUERY
The SG CONFIGURATION QUERY operation has several suboperations,
corresponding to the following types of configuration informa-
tion: subnets, IP addresses, client configuration information,
and vendor specific information.
Each SG CONFIGURATION QUERY operation is read-only to the receiv-
ing server. The particular SG CONFIGURATION QUERY suboperations
are:
Kinnear, Cole & Droms [Page 40]
DRAFT July 1997
o Subnets
The specific subnets managed by this SG are returned in this as
part of this operation.
o IP Addresses
The IP addresses which are managed by this SG within this sub-
net are return as the result of this operation.
o Client Configuration Information
The client configuration information associated with this sub-
net is returned as the result of this operation.
o Vendor Specific Information
Provision is made for vendor specific configuration information
to be returned in the SG CONFIGURATION message. Its format is
TBD, but should be regular even though vendor specific.
o SG PROPOSE CHANGE UPDATE
The SG PROPOSE CHANGE UPDATE message is sent to all of the
servers in a SG to propose a new membership in the server group.
The information sent with this message is an updated list of the
servers in the group. The servers to add to the group and
servers to remove from the group are both listed in the same mes-
sage.
o SG COMMIT CHANGE UPDATE
The SG COMMIT CHANGE UPDATE message is sent to all of the servers
in the SG to commit a change the was proposed in a SG PROPOSE
CHANGE operation.
7.3. Initiating Group Management Operations and Messages
7.3.1. SG CHANGE (operation)
The SG CHANGE operation consists of the the following steps:
o Determine the group membership using an SG CONFIGURATION message.
Find out to whom to send all of the SG CHANGE messages.
Kinnear, Cole & Droms [Page 41]
DRAFT July 1997
o Send a SG PROPOSE CHANGE message to every member of the SG.
This message has the current group specifier in the message,
along with the new group membership. As the joining server
cycles through the existing members of the group, it will be
rationalizing the group specifiers among the group and the entire
group's picture of the membership of the group. If it encounters
a server whose view of the group membership lags behind that of
the server from which the joining server received its idea of
group membership, then it will bring that server up to date.
If, on the other hand, it encounters a server that has a more up
to date version of the group membership than the one from which
it is operating, it will have to update its idea of the group
membership and then start the proposal sequence over. All of the
servers with which it has created proposals will be forced to
update their view of group membership as part of this process.
At the end of this process of proposal generation, all of the
servers in the group share a common picture of both the group
membership as well as the current proposal.
o Reverify the group membership from at lease one server using an
SG CONFIGURATION message.
This is to ensure that all of the members of the group have actu-
ally been sent a SG PROPOSE CHANGE message.
o Check the proposal timer.
The initiating server must have started a timer when it sent out
the first SG PROPOSE CHANGE message, and if that timer has less
than time/2 time left on it, the joining server SHOULD start the
process over.
o Send a SG COMMIT CHANGE message to every member of the SG.
As soon as this completes successfully with one server, the
server has changed the membership of the group, but the initiat-
ing server MUST continue to try to update the other servers as
long as they remain in the server group.
7.3.2. SG DISCOVERY QUERY (message)
This is sent when a server wishes to know the groups to which another
server is a member. It is used primarily when starting up a server
in the initial discovery of the server group configuration.
Kinnear, Cole & Droms [Page 42]
DRAFT July 1997
7.3.3. SG CONFIGURATION QUERY (message)
This message is sent to determine the details of the configuration of
the server group. A server would typically initiate these messages
as part of the process of confirming that it wished to be part of a
particular server group.
The SG CONFIGURATION QUERY operation has several suboperations, cor-
responding to the following types of configuration information:
o Subnets
The specific subnets managed by this SG are returned in this as
part of this operation.
o IP Addresses
The IP addresses which are managed by this SG within this subnet
are return as the result of this operation.
o Client Configuration Information
The client configuration information associated with this subnet
is returned as the result of this operation.
o Vendor Specific Information
Provision is made for vendor specific configuration information
to be returned in the SG CONFIGURATION QUERY message. Its format
is TBD, but should be regular even though vendor specific.
7.4. Responding to Group Management Messages
7.4.1. SG PROPOSE CHANGE UPDATE
Upon receipt of a SG PROPOSE CHANGE UPDATE message, if no existing
proposal exists that has not timed out, a server will create a single
"proposed" group specifier from the current group specifier by incre-
menting the group sequence number by 1. The creation of this pro-
posed group specifier will inhibit the creation of another proposed
group specifier for a 30 seconds.
If an existing proposal exists that has not timed out, the responding
will respond negatively to the SG PROPOSE CHANGE UPDATE message.
Kinnear, Cole & Droms [Page 43]
DRAFT July 1997
DISCUSSION:
Clearly a deadlock situation can occur where two servers are try-
ing to join a group at the same time, and each is working from
"opposite ends" of the group. In this case, where the joining
server gets a failure from a SG PROPOSE CHANGE UPDATE message due
to the existence of a valid proposal that has not timed out, then
the joining server should backoff an amount of time that is based
in part on its IP address before trying again. The exact algo-
rithm is TBD.
This proposed group specifier will not be used in any messages until
it moves to the accepted stage and become the current group specifier
(see below for how it does that).
If a second SG PROPOSE CHANGE UPDATE request is received from a
server, that message will supersede the existing proposal and the
timer will be reset.
DISCUSSION
Is there some possible attack here? Should we limit one servers
proposals from tying up the "proposal" for more than 3 minutes at
a time, for instance?
7.4.2. SG COMMIT CHANGE UPDATE
Upon receipt of a SG COMMIT CHANGE UPDATE message, the current pro-
posal is compared with the data in the SG COMMIT CHANGE UPDATE mes-
sage, and if it compares successfully, the proposed new group becomes
the current group and the group specifier is changed.
Once a SG COMMIT CHANGE UPDATE message is received, the receiving
server MUST examine all of its IP addresses. For every IP address
for which the "last transaction server" is a server which was previ-
ously in the group and is now not in the group, the following action
should be taken:
If the IP address is shown as ever having been BOUND to a client, and
if that client does not now have a different IP address, then the IP
address should be set to BOUND to that client, the lease time should
be restarted for the previously recorded lease time.
DISCUSSION:
This is a key aspect of the protocol in terms of safely removing
possibly partitioned servers from the group. The specific case
Kinnear, Cole & Droms [Page 44]
DRAFT July 1997
that this protects against is as follows.
If a connected server creates a client binding, and successfully
performs a CLIENT BINDING COMPLETE PUSH operation, and then renews
its client's lease for the full lease time -- and then becomes
partitioned, there can be problems if that server is ultimately
removed from the group much later. If the server is partitioned
for longer than the client's lease time, and if all of the other
servers move this IP address to EXPIRED, and if then some server
tries (unsuccessfully) to perform an UNBINDABLE COMPLETE POLL --
which will move the EXPIRED addresses to UNBINDABLE. Now, the
partitioned server has updated the client several times, and the
other servers by this time all believe that the IP address is
UNBINDABLE. If the partitioned server then fails and is removed
from the SG -- the other servers could (in the absence of the
above algorithm) believe that they only need wait the MAXIMUM-
UNPUSHED-LEASE-TIME before then can make those UNBINDABLE
addresses BINDABLE. But in this case that would cause a failure.
Thus, when a server is removed from a SG, each remaining server
must look around for any IP addresses that it previously PUSHED,
and set them up with their previous maximum lease time in order to
catch this case.
7.4.3. SG DISCOVERY QUERY
The server groups to which the current server belongs are returned as
the response to an SG DISCOVERY QUERY message.
7.4.4. SG CONFIGURATION QUERY
The SG CONFIGURATION QUERY operation has several suboperations, cor-
responding to the following types of configuration information:
o Subnets
The specific subnets managed by this SG are returned in this as
part of this operation.
o IP Addresses
The IP addresses which are managed by this SG within this subnet
are return as the result of this operation.
o Client Configuration Information
The client configuration information associated with this subnet
is returned as the result of this operation.
Kinnear, Cole & Droms [Page 45]
DRAFT July 1997
o Vendor Specific Information
Provision is made for vendor specific configuration information
to be returned in the SG CONFIGURATION QUERY message. Its format
is TBD, but should be regular even though vendor specific.
8. SCSP Message Mapping
This section develops the SCSP capabilities supporting the DHCP
interserver protocol. The Server Cache Synchronization Protocol
(SCSP) is found in [1]. The organization of this section is 1) we
present a brief overview of SCSP (and refer to appendices for a more
detailed discussion), 2) we discuss the mapping of the DHCP inter-
server protocol onto SCSP and how the various DCHP interserver mes-
sages are mapped into SCSP messages, 3) we identify the modifications
to the SCSP protocol as identified in [1] necessary for the mapping
of the DHCP interserver protocol onto SCSP, 4) we present the spe-
cific formats of the DHCP protocol specific SCSP records and 5) we
present a list of the open issues with respect to the mapping onto
SCSP.
8.1. SCSP Overview
The Server Cache Synchronization Protocol (SCSP) is a protocol which
provides the generic functions necessary to provide loose synchro-
nization between a set of distributed databases. The protocol, which
is presented in [2], was developed to specifically address to issues
associated with synchronizing the caches of redundant servers which
provide the server functionality of a specific client-server proto-
col. SCSP was built based upon the extensive experience in develop-
ing and running link state routing protocols such as OSPF [3].
Client server protocols for which a redundant server capability is
being developed using SCSP are NHRP [4] and ATM ARP [5]. Here we
present the use of SCSP to synchronize servers supporting the DHCPv4
client-server protocol.
The SCSP protocol consist of three separate sub-protocols, i.e.,
o The "Hello" protocol: this protocol defines and maintains the
status of the inter-server connection,
o The "Cache Alignment" protocol: this protocol defines the cache
synchronization capability for new servers and servers that, for
whatever reason, have lost synchronization, and
o The "Client State Update" protocol: this protocol provides the
ongoing server cache synchronization through asynchronous client
Kinnear, Cole & Droms [Page 46]
DRAFT July 1997
state updates.
These sub-protocols define the semantics and high-level syntax of
generic message sets and their exchanges in support of the capabili-
ties provided. The SCSP associates replica databases into Server
Groups (SG). The SCSP supports both point-to-point and point-to-
multipoint connections between the local servers (LS) and the
directly connected servers DCS(es). We discuss each of these sub-
protocols in more detail in the appendices below.
SCSP defines five message types in the operation of the above subpro-
tocols:
o Hello
o Cache Alignment (CA)
o Cache State Update (CSU) Solicit (CSU_Sol)
o CSU Request (CSU_Req)
o CSU Reply (CSU_Rep).
The Hello and the CA messages are used within the Hello and the Cache
Alignment subprotocol respectively. The CSU_Sol, CSU_Req and CSU_Rep
messages are used to distribute cache records between the distributed
servers of a server group. Full records are called Client State
Advertisement (CSA) records. Summary records, which are essentially
pointers to the full records, are called Client State Advertisement
Summary (CSAS) records.
For a server to request a particular record, it can send a CSU_Sol
message containing the CSAS to indicate the full record of interest.
A server which receives a CSU_Sol is required to respond with a
CSU_Req message containing the full CSA record associated with the
CSAS of the CSU_Sol. The soliciting server follows the receipt of
the CSU_Req with a CSU_Rep to acknowledge receipt. A server which
wishes to communicate a full record to the rest of the SG would
transmit a CSU_Req message containing the full CSA record. This is
acknowledged with a CSU_Rep message.
DISCUSSION
In some cases the CSU_Sol, CSU_Req, CSU_Rep sequence is overkill
when one wants to perform a simple query operation. See the dis-
cussion at the end of Section 8.3 for more details.
For now we accept that these capabilities are generically provided
Kinnear, Cole & Droms [Page 47]
DRAFT July 1997
discuss the DHCPv4 interserver protocol specific overlay on SCSP.
8.2. Mapping DHCP interserver onto SCSP
This section presents the relationship of SCSP to the DHCP inter-
server protocol, the assumptions made in developing this relationship
and the specific mappings of DHCP interserver messages into SCSP.
The assumptions made in defining the DHCP client/server protocol map-
ping onto SCSP are the following:
o On the Issue of Protocol Encapsulation:
The assumption is that the SCSP messages, and in fact all inter-
server messages, are to be defined over UDP. Currently the SCSP
messages within [2] are LLC/SNAP encapsulated.
o On the Interserver over SCSP Layering Model:
The interserver group management protocol will initialize a
server into the group upon initial join, re-booting or re-
connecting. Once this is complete the interserver group manage-
ment protocol will initialize the SCSP protocol to handle the
ongoing operation of the interserver cache alignment and address
management functions.
o On the DHCP Interserver Sub-Protocols:
The current thinking goes as follows. The draft specification
defines three DHCP interserver sub-protocols, i.e., the 'Client
Binding Management' protocol (see Section 4), the 'Address Man-
agement' protocol (see Section 5), and the 'Group Management'
protocol (see Section 7). The 'Client Binding Management' sub-
protocol addresses the core of the interserver protocol in that
it distributes and maintains the client binding records over the
distributed SG. This sub-protocol is to be mapped onto SCSP and
is assigned a unique SCSP 'Protocol ID' value, e.g., the SCSP
ProtID = 4 assigned to DCHP. For this draft we assume that the
Group Management sub-protocol is run on a separate UDP port from
the SCSP UDP port. The Group Mgmt sub-protocols will be assigned
a unique UDP port number = tbd. We had no compelling reason to
carry the Address Management subprotocol on SCSP as for the
Client Binding protocol, however for this draft we mantain both
these sub-protocols within SCSP. If at a later date it is deemed
useful to separate these two protocol 1) we can define separate
SCSP protocol types for the Cache Management and the Address Man-
agement protocols, yet support them with a common Hello protocol
link via the Hello protocol Family type field or 2)we can move
Kinnear, Cole & Droms [Page 48]
DRAFT July 1997
the address management sub-protocol out from SCSP as in the case
of the Group management sub-protocol.
The mappings between the interserver messages and the SCSP mes-
sages will cover the interserver messages handling client binding
and address management, but not the group management protocol
functions of the interserver protocol. The group management
messages are to be defined outside of SCSP, however these mes-
sages will follow the syntax of the SCSP message sets to simplify
the parsing of the total message sets required within the DHCP
interserver protocol.
The client binding management operations are CLIENT BINDING COM-
PLETE PUSH and CLIENT BINDING POLL. CLIENT BINDING COMPLETE PUSH
is required to distribute binding information and to increase the
initial lease period to the desirable lease period. The CLIENT
BINDING POLL is required to solicit information on client bind-
ings in the event that the specific server has no record of the
client requested binding. The Interserver messages supporting
these operations are the CLIENT BINDING UPDATE and the CLIENT
BINDING QUERY messages, respectively. The SCSP records for these
operations are 'Binding' records for the update and query mes-
sages.
The Address Management operations are UNBINDABLE COMPLETE POLL
and TRANSFER. The UNBINDABLE COMPLETE POLL initializes an
address as bindable by the LS. The TRANSFER allows for the
transfer of a block of bindable addresses between servers. The
Interserver messages supporting these operations are the UNBIND-
ABLE QUERY and the TRANSFER messages. The SCSP records for these
operations are 'Address' records for the UNBINDABLE QUERY and
'Bindable Block Address' records for the TRANSFER messages.
The Group Management messages are SG DISCOVERY Query, SG CONFIGU-
RATION QUERY, SG PROPOSE CHANGE UPDATE and SG COMMIT CHANGE
UPDATE. The SCSP records associated with these operations are
'SG Specifier' records for the SG DISCOVERY QUERY, 'SG Subnets'
records for the SG CONFIGURATION QUERY, 'SG Members' records for
the SG DISCOVERY Query, and 'SG Proposed Members' records for the
SG PROPOSE CHANGE UPDATE and SG COMMIT CHANGE UPDATE messages.
o On DHCP Interserver Authentication:
The interserver protocol will rely on the authentication exten-
sions within SCSP for the SCSP message authentication between
servers within a server group. The authentication of the inter-
server group management protocol messages are tbd.
Kinnear, Cole & Droms [Page 49]
DRAFT July 1997
o On the Notion of Server Ownership of Binding Records:
It will be assumed that once the initial client binding record is
generated by a particular server, that record will indicate that
server as the originating server in the SCSP 'Originating Server
ID' field. Any further changes to that binding, whether by the
originating server or by another server, e.g., the originating
server is down and the client is Rebinding and getting a lease
extension from another server, that server does change the Origi-
nating Server ID in the SCSP record field to indicate itself as
the last transaction server.
o On a More Efficient Cache Alignment Process:
The cache alignment process can be made more efficient if the
servers time stamp their cache records. In the event that the
connections between servers fails, the servers determine and
record the failure time. Upon reconnecting and cache alignment,
the SCSP CRL list can be limited to those records that are more
'recent' than the failure and therefore greatly reduce the time
and the bandwidth required. The details are presented below.
Also, it is not necessary to perform a cache alignment of the
address records for the proper operation of the Interserver pro-
tocol. Therefore, we assume that the SCSP cache alignment pro-
cess will not include these address records when building the
SCSP CRL.
o On the More Recent Record Determination:
SCSP relies on the ability of identifying the more recent-ness of
records when aligning and updating the cache based upon the CSA
Sequence Number. For binding records this implies that in situa-
tions where it is clear that a single server is updating the
binding, e.g., extending the lease, then it should increment the
CSA Sequence number by one. However there are situations in DHCP
where multiple servers can simultaneously update the client bind-
ing and it is not clear which of these updated bindings is
accepted by the client, e.g., the client is in the rebinding
state and the originating server is down and the other servers
received the client broadcast request and the client gets multi-
ple DHCPACKs extending the lease. In these situations the
servers are required to increment the CSA sequence numbers by one
and indicate that they are the last transaction server. Then,
when a server caches the record, if it already has a cache record
for that binding (as indicated by the Cache Key) it should
replace the existing record only if the new record indicates a
lease period which is greater than the existing record.
Kinnear, Cole & Droms [Page 50]
DRAFT July 1997
o On Maximally Defined Binding Records (or the B.Hibbs' Question):
B.Hibbs' posed the question regarding the nature of the configu-
ration synchronization of the servers within the same SG; Does
the DHCP Interserver protocol require synchronization of all con-
figuration parameters or a subset? We are assuming that there is
a minimal set of configuration and client binding information to
be synchronized across the members of the SG to ensure the cor-
rect operation of the DHCP Client/Server protocol. This informa-
tion must be carried in the interserver messages to synchronize
the members in the SG with respect to this information. Further,
there may be other client binding information that the members
want to communicate; we currently have this information encoded
as optional in this draft.
The parameters encoded into the 'Client Binding' records are
those which are minimally required for the correct operation of
the DHCP Client/Server protocol. The interserver protocol should
allow for situations where the configuration of the servers of
the same server group are not strictly aligned; their configura-
tions are only required to be aligned in the specification of the
subnets and masks that are covered with a SG and the list of
assignable addresses within each of the subnets. However,
because clients DHCPDISCOVER messages can contain client specific
requests for parameters, it may be desirable to embed a fuller
set of parameters (committed to the client in the DHCPOFFER mes-
sage) within the CSA record. This fuller set of parameters may
be included in the initial CLIENT BINDING COMPLETE PUSH (encoded
in the optional fields location in the record). The server in
receipt of a CLIENT BINDING COMPLETE PUSH may chose not to cache
or forward these optional parameters.
o On Knowledge Obtained Through the SCSP Hello protocol:
The SCSP Hello protocol maintains current status of the inter-
server connectivity through a polling mechanism. This status
information can be used to influence the actions of the LS, e.g.,
in the event that the LS has lost connectivity from a DCS, then
it should not perform a COMPLETE POLL operation.
o On the SG Connectivity:
It is likely that the servers of the SG are required to be fully
interconnected, i.e., a LS is a DCS to all other servers of the
SG. It was first thought that this would aid in determining the
status of the SG, i.e., whether the SG was 'up' (fully function-
ing) or 'down' (not fully functioning). However on further
inspection this is not true, i.e., the loss of connectivity
Kinnear, Cole & Droms [Page 51]
DRAFT July 1997
between a pair of servers in a fully connected SG does not imply
that the other servers are not still connected to the other
servers. Full mesh connectivity may still be required for the
correct operation of the Address Management protocol. This is
currently under study.
When a new server wishes to join a server group, it must initialize
itself to the other members of the server group through the above
defined interserver Group Management Protocol. Once this has
occurred, the local server must initiate SCSP which then will align
its client binding cache to that of the server group. It should then
acquire Bindable addresses and fully participate in the on-going
client binding update functions of the server group.
This process is outlined in the below state diagram for the DHCP
interserver protocol. The Group Management protocol handles the new
server joining the group. Once this has occurred, the new server and
all the other servers of the server group initiate the SCSP Hello
Protocol on a pairwise basis. Per the discussion in the SCSP speci-
fication, once bi-directional connectivity is re-verified and now
monitored within the SCSP Hello protocol, the servers enter into the
cache alignment and then the ongoing cache and address management
functions. In the event that the servers transition to the 'DOWN'
state, polling will continue until connectivity is re-established.
The Group Management Protocol does not allow additions to the member-
ship in the event that the SG is down. However it does allow for the
removal of a server from the SG while another server is re-booting or
disconnected. Therefore a re-booting or re-connecting server cannot
be assured that the SG generation has remained constant during the
'DOWN' period. Therefore, in the event that the generation number of
the SG has changed as indicated through the generation number con-
tained within the interserver messages, the server needs to update
its notion of the server group through the procedures identified in
the group management protocol prior to aligning its cache.
Kinnear, Cole & Droms [Page 52]
DRAFT July 1997
+------------+
| Group |
| Management |
| Protocol |
+------------+
|
|
V
+------------+
| SCSP |
| Hello |
+------------+
/ ^ \
/ | \
V | V
+--------------+ | +---------------+
|'Binding Mgmt'| | |Null'Addr Mgmt'|
| Cache |---+----| Cache |
| Alignment | | | Alignment |
+--------------+ | +---------------+
| | |
| | |
V | V
+--------------+ | +------------+
|'Binding Mgmt'| | | 'Addr Mgmt'|
| Cache Update |---+----|Cache Update|
+--------------+ +------------+
Figure 8.2-1 Interserver State Flow Diagram
For operational efficiency, the servers should implement a scheme to
limit the number of cache records to exchange during the cache align-
ment process. For example, a SG could easily be managing 10,000
client records and the bandwidth requirements to pass even the sum-
mary records required to build the CRL table can be quite large.
Therefore, for the 'Cache Management' sub-protocol, the servers
should record the times at which the cache entries were received or
created or modified. When the CAFSM transitions for a particular DCS
to the down state, t(down) should be recorded. Then when the CAFSM
enters the cache alignment state, the CRL list is to be built up
based upon only those records with time stamps more recent then
t(down) - F, where F is a factor to be set to a multiple of the Hel-
loInterval x DeadFactor. We recommend that the multiple be 10. In
the event that the LS crashed (causing the transition to the down
state), then t(down) should be set to the last record time stamp when
the LS reboots. In the event that the server has just joined the SG,
the CRL should be built up from all of the current cache records.
Kinnear, Cole & Droms [Page 53]
DRAFT July 1997
The interserver messages associated with the Client Binding Manage-
ment are: CLIENT BINDING QUERY for the CLIENT BINDING POLL opera-
tion, and CLIENT BINDING UPDATE for the CLIENT BINDING COMPLETE PUSH
operation. These are discussed in detail in the following list
items:
o The CLIENT BINDING QUERY message queries another server regarding
the status of a particular binding. Within the SCSP protocol,
this exchange is accomplished by the LS sending a Client State
Update_Solicit (CSUS) message with the Client State Advertisement
Summary (CSAS) 'Address record' of the IP address in question.
The DCS responds with the CSU_Request message with the Client
State Update (CSU) record associated with the CSAS. The LS then
replies with a CSU_Reply with the 'A-bit' set.
o The CLIENT BINDING UPDATE message updates another server with a
new, or changed, client binding. Within the SCSP protocol, this
exchange is accomplished with the CSU_Request message carrying
the specific CSA 'Binding record' of the client binding in ques-
tion. The DCS responds with the CSA-Reply with the 'A-bit' set.
The interserver messages associated with the Address Management are:
UNBINDABLE QUERY for the UNBINDABLE COMPLETE POLL operation, and
TRANSFER messages for the TRANSFER operation. These are discussed in
detail in the following list items:
o The UNBINDABLE QUERY message queries another server of the SG
regarding the status of a particular address with the intent of
making that address bindable to the LS. Within the SCSP proto-
col, this exchange is accomplished by the LS sending a
CSU_Solicit with the CSAS 'Address' record of the IP address in
question to all other servers of the SG. The DCSes respond with
the CSU_Request message with the CSA 'Address' record indicating
the status of the address within the DCS. The LS then replies
with the CSU_Reply message to the DCS with the 'A-bit' set.
o The 'TRANSFER' operation is initiated by the LS to request a
transfer of bindable addresses from the DCS to the LS. Within
the SCSP protocol, this exchange is accomplished by a two step
process. First, the LS sends a CSU_Request message with the CSA
'Subnet Bindable Addresses' record to the DCS, which then
responds with a CSU_Reply. The CSA 'Subnet Bindable Addresses'
record indicates the subnet in question, the number of BINDABLE
addresses owned by the LS and the number of additional BINDABLE
addresses the LS is requesting. Second, this is immediately fol-
lowed by the DCS sending a CSU_Request message with a CSA 'Subnet
Bindable Address' record for the given subnet in question. The
DCS' CSA 'Subnet Bindable Addresses' record indicates the subnet
Kinnear, Cole & Droms [Page 54]
DRAFT July 1997
in question and the number and address of the IP addresses that
the DCS is transferring to the LS based upon it's previous
request. This is based upon the DCS' current understanding of
the supply of bindable addresses within the LS and its local
knowledge of its own set of bindable addresses for this subnet.
This CSU_Request will generate a CSU_Reply from the originating
LS. When sending the CSU_Request message, the DCS sets the
addresses it is transferring to the LS as UNBINDABLE. The LS
then moves these addresses to its list of BINDABLE addresses and
sends a CSU_Reply to the DCS with the 'A-bit' set.
The interserver messages associated with the Group Management opera-
tions are: SG DISCOVERY QUERY, SG CONFIGURATION QUERY, SG PROPOSE
CHANGE UPDATE, and SG COMMIT CHANGE UPDATE messages. These are dis-
cussed in detail in the following list items:
o The SG DISCOVERY QUERY message queries the DCS for its list of
current SG in which it is participating. Within the SCSP proto-
col, this exchange is accomplished by the LS sending a
CSU_Solicit with the CSAS 'Server Groups' record and the DCS
replys with the CSU_Request message containing the CSA 'Server
Groups' record. This record contains the list SG specifiers,
i.e., SG ID and SG Generation Number (GN) pairs. The LS replies
with a CSU_Reply.
o The SG CONFIGURATION QUERY message queries the DCS for its con-
figuration information. This information is passed within the
'SG Subnets Configuration' record. The LS initiates this query
by sending a CSU_Solicit containing the CSAS 'SG Subnets Configu-
ration' summary record. The responds with a CSU_Request contain-
ing the CSA 'SG Subnets Configuration' record. The LS replies
with the CSU_Reply message.
o The SG PROPOSE CHANGE UPDATE message proposes the new member to
the rest of the SG. This is accomplished with a SCSP CSU_Req
message carrying the 'SG Proposed Members' record. The SG COMMIT
CHANGE UPDATE message consummates the new server joining the SG.
Once the joining member has received positive CSU_Reply from all
of the current members of the SG as part of the proposal phase,
it then moves to the join commit phase. The new server now
issues an SCSP CSU_Req message with the 'SG Members' record car-
rying the newly joined member to the list of servers of the SG.
o The SG PROPOSE CHANGE UPDATE message may also be used to propose
the removal of an existing server from the membership of the SG.
This is accomplished with a SCSP CSU_Req message carrying the 'SG
Proposed Members' record containing all of the existing members
of the SG minus the server ID to be removed. The SG COMMIT
Kinnear, Cole & Droms [Page 55]
DRAFT July 1997
CHANGE UPDATE message consummates the existing server leaving the
SG. Once the removing member, i.e., the member who is actively
removing the existing member from the group, has received posi-
tive CSU_Reply from all of the current members of the SG (except
for the member being removed) as part of the proposal phase, it
then moves to the remove commit phase. The removing server now
issues an SCSP CSU_Req message with the 'SG Members' record car-
rying the new membership minus the removed server.
8.3. Necessary Modifications to SCSP
The SCSP modifications required to support the DHCP interserver pro-
tocol are as follows:
o The operation of the SCSP protocol in this application is initi-
ated upon the successful completion of the interserver 'Group
Management Protocol'.
o The SCSP messages, and in fact all of the DHCP interserver mes-
sages are carried in UDP packets. Therefore a UDP port number
needs to be defined for SCSP.
DISCUSSION:
Currently SCSP is defined only for NMBA networks. This mani-
fests itself in two ways; a) the operation of the SCSP proto-
col is initiated upon the establishment of NBMA connectivity,
i.e., a virtual circuit being established, and b) the SCSP
messages are encapsulated into link level frames using the
LLC/SNAP encapsulation method.
Instead of relying upon the establishment of a virtual circuit
connection, the interserver protocol will initiate the SCSP
protocol based upon the results of the 'Group Management Pro-
tocol'. This divorces the operation of the interserver proto-
col from the specifics of the link layer. Also, by carrying
the messages within UDP, the protocol achieves independence in
the deployment and proximity of the servers which are members
of the same server group, i.e., servers are not required to
have an interface on a common subnet.
Because SCSP provides a generic capability to synchronize
caches in distributed servers, it is best to define a separate
UDP port number for the 'generic' SCSP protocol and a separate
UDP port for the DHCP interserver Group Management protocol.
These UPD port numbers are tbd.
Kinnear, Cole & Droms [Page 56]
DRAFT July 1997
o A SG Generation Number SCSP extension field needs to be defined.
DISCUSSION:
We have defined the notion of a Server Group Generation Number
to distinguish between the various instantiations of a partic-
ular SG. The membership of a particular SG will change over
time. Because it is necessary for the correct operation of
the DHCP interserver protocol for each server to know the cur-
rent membership, it was deemed necessary to define a Genera-
tion Number which is incremented each time a new server joins
the SG or an existing server is removed from the SG. This GN
is to be carried in every interserver message. No obvious
place existed with the SCSP message formats to carry such
information. Therefore, we have chosen to define a new SCSP
extension type and will carry the GN in this method.
o Some modification to the Authentication extension in the SCSP
protocol may be required.
DISCUSSION:
Currently SCSP states that the authentication extension covers
the SCSP message other than the extensions. However we have
chosen to carry a new extension within the SCSP messages; the
Generation Number. Ideally we would prefer that this exten-
sion be protected by the authentication extension. Because it
is not, we will also include the Generation Number in the SG
Specifier record. Through this record a server may reverify
the current Generation Number through a protected channel.
o The three step Solicit_Request_Reply seems excessive when one
server wishes to simply query another server. Perhaps this could
be simplified (when desirable) by adding a bit to the CSU_Solicit
message indicating whether the soliciting server wishes the DCS
to expect or not to expect a CSU-Rep from the soliciting server.
DISCUSSION:
Currently SCSP states that the three step process of CSU_Sol
followed by a CSU_Req which is then followed by a CSU_Rep. In
certain situations this may be a desirable sequence. However,
in other situations it may not be necessary. When the CSU_Sol
is sent a CSUSReXmtInterval timer is set which tracks the sta-
tus of the receipt of the requested CSU_Req records. For sim-
ply queries, this re-transmit timer may be sufficient. There-
fore, it seems reasonable that DCS should expect a CSU_Rep
from the LS which sent the CSU_Sol message.
Kinnear, Cole & Droms [Page 57]
DRAFT July 1997
8.4. DHCP Specific CSA and CSAS Records
This section presents the CSA and the CSAS records specific to the
DHCP inter-server protocol. The mappings of the interserver protocol
onto SCSP messages discussed in the previous section relys upon the
definition of a number of record types. These record types will be
distinguished within the CSAS defined 'Cache Key', which for the pur-
pose of running the DHCP interserver protocol will consist of a
TYPE/Key pair. The following CSAS and CSA record types are required
to run the interserver protocol:
For Client Binding Management:
o Binding Record - contains the complete client binding informa-
tion.
For Address Management:
o Address Record - contains the status of a specific IP address,
e.g., unbindable, bindable, bound, expired, etc.
o Subnet Bindable Record - contains information regarding the sub-
net addresses, e.g., number of bindable addresses.
For Group Management:
o SG Specifier Record - contains the current Server Group speci-
fiers, i.e., the SG ID (which is fixed for the duration of the
life of the SG) and the SG Generation Number which is incremented
for each new server add or old server delete.
o SG Members Record - contains the current list of member servers
of the SG.
o SG Subnets Configuration Record - contains a list of all subnets,
i.e., subnet address and mask, for all of the subnets served by
the SG as well as the assignable addresses per subnet, and poten-
tially other configuration parameters necessary for the proper
operation of the DHCP interserver protocol.
o SG Proposed Members Record - contains a list of the proposed mem-
ber servers of the SG used in the group join proposal process.
This record has a finite duration associated with it and times
out if the proposed join fails.
Kinnear, Cole & Droms [Page 58]
DRAFT July 1997
8.4.1. The SCSP CSAS Records for the Interserver Protocol
The CSAS record is completely specified in [2]. The format of the
CSAS record is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.1-1 SCSP CSAS Record Format
where:
o Hop Count - this represents the number of hops that the record
may take before being dropped.
o Record Length - this is the length in bytes of the CSAS record if
stand-alone, otherwise it is the length in bytes of the CSAS
record and the protocol specific part of the cache entry com-
bined, i.e., the length of the CSA record.
o Cache Key Length - this is the length of the Cache Key field in
bytes.
o Originator ID Length - this is the length of the Originator ID
field in bytes.
o N bit - this bit, when set, signifies a Null record. This may
be the case when the LS receives a solicitation for a record that
has been released by the DHCP client.
o CSA Sequence Number - this field contains the sequence number
that identifies the 'newness' of a CSA record instance being sum-
marized. This number is assigned by the originator of the CSA
record, i.e., the last transaction server.
Kinnear, Cole & Droms [Page 59]
DRAFT July 1997
o Cache Key - is an opaque string used by the receiving server to
identify the cache entry referred to by the record. For the pur-
poses of running the DHCP interserver protocol, the Cache Key
will be encoded as a Type/Key pair, where the type is an 8 bit
field and the length of the Key is derived from the Cache Key
Length field in the header. The Type indicates the type of
record and equivalently the Interserver message type, e.g.,
Unbindable Address Query, SG Configuration Query, etc. The 8 bit
type encodings are defined in the table below.
o Originator ID - this field contains an ID which is administra-
tively assigned to the server which is the originator of the CSA
record. For the DHCP interserver mapping, the the Originating
Server ID is chosen to be the IP address of the server. In the
event that the server has multiple IP addresses assigned to it,
then the Originating Server ID is set to the IP address with the
highest value.
The CSAS record is specified by SCSP except for the specifics of the
Cache Key and the Originator ID.
For the purpose of the DHCP interserver specification, the Originat-
ing Server ID is chosen to be the IP address of the server. In the
event that the server has multiple IP addresses assigned to it, then
the Originating Server ID is set to the IP address with the highest
value.
The Cache Key used is dependent upon the specific CSAS record in
question. The table below identifies the specific Cache Keys for the
various CSAS records within the DHCP interserver protocol. These are
composed of a type and key field, both of which are identified in the
table.
Kinnear, Cole & Droms [Page 60]
DRAFT July 1997
Table 8.4.1-1 Cache Keys for the various CSAS and CSA records
Record Type | Encoding | Key
--------------------------------------------------
| |
Client Binding | 0x00 | Client ID
| | or hwaddr
Address | 0x10 | IP addr
| |
Subnet Bindable Addrs | 0x11 | Subnet/Mask *
| |
SG Specifiers | 0x20 | IP addr
| |
SG Subnet Configs | 0x21 | SG ID
| |
SG Members | 0x22 | SG ID/SG GN **
| |
SG Proposed Members | 0x23 | SG ID/SG GN **
* The subnet address and the subnet mask will be encoded as 32 bit
strings with the subnet address followed by the subnet mask.
** The SG ID and SG GN are encoded as 16 bit strings with the SG
ID first, immediately followed by the SG GN.
8.4.2. The SCSP CSA Records for the Interserver Protocol
There are several types of DHCP specific CSA records defined corre-
sponding to each of the CSAS record types discussed above and found
in Table 8.4.1-1.
For many of these records, DHCP options appear in the records in the
same format as specified in [7].
The records are:
o The Client Binding record carries the complete client binding
information. The Key for this record is the chaddr or the
'client ID' from the optional DHCP extension. This is utilized
in the Cache Mgmt sub-protocol in handling the COMPLETE PUSH,
POLL and SCSP cache alignment operations.
o The Address record carries the information required to achieve
the desired response from the CSU_Solicit message. The Key is
the IP address. This is utilized in the Address Mgmt sub-
protocol in handling the UNBINDABLE COMPLETE POLL operation.
Kinnear, Cole & Droms [Page 61]
DRAFT July 1997
o The Subnet Bindable Address record carries the information
required to determine the status of the available IP addresses
which are bindable to the DCS and which it is will to transfer to
the LS. The Key for this record is the subnet address and mask
of the subnet in question. This is utilized in the Address Mgmt
sub-protocol by the TRANSFER operation.
o The SG Specifier record contains the total list of SG specifiers,
i.e., SG ID and SG GN pairs, of which the server in question is
currently a member. This is utilized in the Group Mgmt sub-
protocol by the DISCOVERY operation. The Key for this record is
the Server ID, i.e., the IP address of the server.
o The SG Members record contains a list of the Server IDs which
comprise the SG in question. This is utilized in the Group Mgmt
sub-protocol by the DISCOVER MEMBERS operation. The Key for this
record is the SG Specifier, i.e., the SGID and SG GN pair.
o The SG Proposed Members record contains a list of the SG members,
including the newly proposed member, of the server group. This
is utilized in the Group Mgmt sub-protocol by the PROPOSE JOIN
operation. The Key for this record is the SG Specifier, i.e.,
the SGID and SG GN pair where the SG GN is one greater than the
current GN of the SG.
8.4.2.1. Binding Records
The approach taken in defining the Client Binding record is as fol-
lows. It is possible, while still maintaining the correct operation
of the DHCP client/server protocol, to have the different server con-
figurations within the same server group with respect to certain
parameters. For these parameters we do not require synchronization
of the server configurations and we make the passing of these parame-
ters as optional. However there are some configuration parameters
and binding information which is critical to the correct operation of
the protocol. For these client parameters we require that they be
included in the Client Binding records. The minimal, required set of
parameters to be sent in the Client Binding are the IP address
(ciaddr), the lease period, the last transaction type, the client
hardware address, the Client-Identifier and the Renewel (T1) and
Rebinding (T2) Time values (if present in the DHCP options extensions
of the DHCPACK).
The format of the CSA Binding record for the DCHP inter-server proto-
col is:
Kinnear, Cole & Droms [Page 62]
DRAFT July 1997
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LTT |resrv'd| HTYPE | HLEN | resrv'd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHADDR (HLEN in octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIADDR (4 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Transaction Time (4 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address Lease Time (encoded as tag=51) (6 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional ClientID (encoded as tag=61) (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Renewal Time (encoded as tag=58) (6 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Rebinding Time (encoded as tag=59) (6 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other desirable DCHP extensions (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Option (encoded as in BOOTP options, tag=255) (1 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.1-1 DHCP inter-server CSA Binding record format
where:
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
o LLT - indicates the Last Transaction Type. The allowed LTTs are:
DHCPREQUEST/SELECTING (0x0), DHCPREQUEST/REBINDING (0x3), DHCPRE-
QUEST/RENEWING(0x2), DHCPREQUEST/INIT-REBOOT (0x1), DHCPRELEASE
(0x4), and EXPIRATION (0x5).
o HTYPE - hardware address type (defined in [1])
o HLEN - hardware address length
o CHADDR - client hardware address
o CIADDR - client IP address (if assigned). If not assigned, this
field is all 0s.
Kinnear, Cole & Droms [Page 63]
DRAFT July 1997
o Last Transaction Time - the time from now in seconds of the last
transaction time associated with the LTT as indicated in the mes-
sage.
o IP Address Lease Time - the IP Address Lease Time encoded as in
the DHCP options and BOOTP vendor extensions defined in [7].
This represents the time from now that the client lease is to
expire.
o (Optional) Client ID - this field is the optional Client ID
encoded as in the DHCP options and BOOTP vendor extensions
defined in RFC 2132 [7]. If present, the Client ID is the
'search string'.
o (Optional) Renewal Time - this field is the optional Client
Renewal Time (T1) as encoded in the DHCP options and BOOTP vendor
extensions defined in RFC 2132 [7].
o (Optional) Rebinding Time - this field is the optional Client
Rebinding Time (T2) as encoded in the DHCP options and BOOTP ven-
dor extensions defined in RFC 2132 [7].
o Remaining Options - any remaining options carried in the original
DHCPOFFER message to the client encoded as in the DHCP options
and BOOTP vendor extensions defined in [7]
o End option - determines the end of the CSAS record
DISCUSSION:
As discussed in the previous section on the CSAS record for-
mat, the format shown above is intended to be the Binding type
CSA record. The binding record is used in the PUSH and COM-
PLETE PUSH operations to transfer to the DCSes the newly cre-
ated or changed binding and in the cache alignment procedures.
The structure of the Client Binding is defined, for the pro-
pose of the DHCP interserver protocol into a mandatory part
and an optional part. The mandatory part is everything upto
and including the (Optional) Rebinding Time. The optional
part is everything following the (Optional) Rebinding Time.
The PUSHing server may include any additional parameters which
were part of the DHCPACK message to the client within the
Client Binding Record and encode this as defined in the the
DHCP options and BOOTP vendor extensions defined in RFC 2132
[7]. The server which is the recipient of the PUSH may chose
to save and forward these optional parameters in the record or
may chose not to save and forward these optional parameters.
Kinnear, Cole & Droms [Page 64]
DRAFT July 1997
8.4.2.2. Address Records
The format of the CSA Address record for the DCHP inter-server proto-
col is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ST | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.2-1 DHCP inter-server CSA Address record format
where:
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
o ST - represents the state of the (client) record, e.g., unbind-
able, bindable, bound, expired, polling, static
DISCUSSION:
The Address record is used within the UNBINDABLE COMPLETE POLL
operation to move an unbindable address to a bindable address.
The POLLed server returns the Address record indicating the
current status of the address within the server. If all of
the servers indicate that the address is unbindable, then and
only then will the LS move the address to its Bindable pool.
The ST field indicates the servers view of the state of the
address. The states (defined in Section 3.4.2) are: UNBIND-
ABLE, POLLING, BINDABLE, BOUND, PUSHED, and EXPIRED.
The IP address states are encoded in the following manner:
Kinnear, Cole & Droms [Page 65]
DRAFT July 1997
Table 8.4.2.2-1 IP Address State Encodings
IP Address State | Encoding
--------------------------------------------------
|
UNBINDABLE | 0x01
POLLING | 0x02
BINDABLE | 0x03
BOUND | 0x04
PUSHED | 0x05
EXPIRED | 0x06
8.4.2.3. Subnet Bindable Addresses Record
The CSA Subnet Bindable Addresses record indicates the set of
addresses that a server is willing to TRANSFER to a requesting
server. This record is used in the TRANSFER operation.
The format of the CSA Subnet Bindable Addresses record for the DCHP
inter-server protocol is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. Addresses |No. Addr.Ranges|R| reserved |No.Ownd|No.Reqd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of IP Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.3-1 DHCP inter-server CSA Subnet Bindable Addresses record
format
where:
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
o No. Address - indicates the number of IP addresses contained
within the subnet record. These are the addresses that the DCS
is transferring to the LS as part of the TRANSFER operation.
This is set to 0 when the R-bit is set to 1 (see R-bit below).
Kinnear, Cole & Droms [Page 66]
DRAFT July 1997
o No. Addr. Ranges - indicates the number of IP address ranges of
the form 135.16.114.5 to 135.16.114.235. These will immediately
follow the listing of the individual addresses. This is set to 0
when the R-bit is set to 1 (see R-bit below).
o R - represents the request bit. When this bit is set to 1, it
indicates that the LS is requesting BINDABLE addresses from the
DCS as part of the TRANSFER operation. When it is set to 0, it
indicates that the DCS is transferring these addresses to the LS.
o No. Ownd - indicates the current number of BINDABLE addresses
owned by the LS when the R-bit is set to 1.
o No.Reqd - indicates the number of additional BINDABLE addresses
requested by the LS when the R-bit is set to 1.
o List of IP Addresses - this is a consecutive list of IP address
and address ranges.
DISCUSSION:
The Subnet record is used in the TRANSFER operation to indi-
cate 1) the list of bindable IP addresses that the DCS is
willing to transfer to the LS when the R bit is 0, and 2) the
IP addresses that the LS is requesting when the R bit is 1.
Further, it may be useful to develop similar records for Sub-
net UNBINDABLE, BOUND, PUSHED, and EXPIRED address. They can
have an identical record format and be distinguished through
the 8 bit type field encoded into the SCSP Cache Key. The
utility of these record types is TBD.
8.4.2.4. SG Specifier Record
The CSA SG Specifier Record indicates the total list of DHCP Inter-
server protocol Server Groups that the DCS is currently a member.
This is used in the Group Management subprotocol during the initial
contact of a prospective new member to the Server Group.
The format of the CSA SG Specifier Record for the DCHP inter-server
protocol is:
Kinnear, Cole & Droms [Page 67]
DRAFT July 1997
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|No. Specifiers | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Specifier Pairs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.4-1 DHCP inter-server CSA SG Specifiers record format
where:
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
o No. Specifiers - is a count of the number of specifier pairs con-
tained within this CSA record.
o List of Specifier Pairs - represents a consecutive listing of the
specifier pairs of which the DCS is current a mamber. The encod-
ing of the specifier pairs is SG ID first, which is a 16 bit
string, followed by the SG Generation Number, which is also a
16-bit string.
DISCUSSION:
This record is initially requested by a server which is inter-
ested in joining a DHCP Interserver Server Group and has been
configured with the IP address of a server to first contact.
The first contacted server then replies with the SG Specifier
record. This record can also be solicited when a server,
which an existing member of a group becomes uncertain regard-
ing the current Generation Number of the group.
The SG Generation Number, obtained from this record, is car-
ried in every DHCP Interserver protocol message, encoded as an
extension to the SCSP message extension fields. The extension
encoding is TBD.
8.4.2.5. SG Subnets Configuration Record
The CSA SG Subnet Configuration Record carries SG configuration
information necessary to ensure the correct protocol operation of the
group. The encoding of this record is essentially the subnet address
and mask followed by the pool of addresses which are dynamically
Kinnear, Cole & Droms [Page 68]
DRAFT July 1997
managed by the Server Group for this subnet. The encoding of the
address pool with be consistent with the address pool encoding of the
Subnet Bindable Addresses Record discussed in Section 8.4.2.3 above.
Other configuration parameters may be including if deemed important
to the correct operation of the DHCP interserver protocol.
Section 7.2 specifies that additional information (specifically
client configuration information and vendor specific configuration
information) will be also be available. The precise details of how
this information is encoded is TBD.
The format of the CSA SG Subnets Configuration Record for the DCHP
inter-server protocol is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. Subnets | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Pool of first subnet (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Pool of last subnet (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.5-1 DHCP inter-server CSA SG Subnets Configuration record
format
where:
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
o No. Subnets - indicates the number of subnet configurations con-
tained in this record.
Kinnear, Cole & Droms [Page 69]
DRAFT July 1997
o Subnet Address - this is the subnet address of the subnet for
which the following address pool is related.
o Subnet Mask - this is the mask of the subnet in question.
o Address pool of subnet - this is a listing of the address pool
for which this SG can allocate from for this particular subnet.
The encoding will follow the address pool encoding for the Subnet
Bindable Addresses record. Therefore, the address pool should
contain two count fields, the first indicating the number of
individually listed addresses, followed by another field indicat-
ing the number of address ranges. These are then followed by the
list of individual IP addresses and then the list of address
ranges.
DISCUSSION:
The total list of configuration items to be incorporated into
this record needs to be further fleshed out. Currently this
record is planned to contain a list of the subnets and the
address pools associated with each from which this SG can
allocate. If other configuration parameters are deemed neces-
sary for the proper operation of the DHCP Interserver proto-
col, then these need to be incorporated into this record.
8.4.2.6. SG Members Record
The CSA SG Members Record indicates the list of the current SG mem-
bers, in the opinion of the sending server, including itself.
The format of the CSA SG Members Record for the DCHP inter-server
protocol is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. Server IDs|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Server IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.6-1 DHCP inter-server CSA SG Members record format
where:
Kinnear, Cole & Droms [Page 70]
DRAFT July 1997
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
o No. Server IDs - this is the number of Server IDs contained
within this record.
o P bit - the Proposal bit is used to indicate that this record is
a current group members record (here set to 0) or a proposed
group members record (discussed in the next section).
o List of the Server IDs - this is a consecutive list of Server IDs
which comprise this server's view of the current SG membership.
The Server IDs are IP addresses associated with one of the
server's interfaces.
8.4.2.7. SG Proposed Members Record
The CSA SG Proposed Members Record indicates the list of the current
SG members, in the opinion of the sending server, and adding itself.
This is a temporary record (with a lifetime associated with the
period during which a Group Management SG CHANGE operation has to
complete). Once the SG COMMIT CHANGE UPDATE is received, this record
replaces the old SG Members record as the new member record contain-
ing the newly joined server.
The format of the CSA SG Proposed Members Record for the DCHP inter-
server protocol is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. Server IDs|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Server IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8.4.2.7-1 DHCP inter-server CSA SG Proposed Members format
where:
o CSAS Record - represents the full CSAS record as identified in
Section 8.4.1.
Kinnear, Cole & Droms [Page 71]
DRAFT July 1997
o No. Server IDs - this is the number of Server IDs contained
within this record.
o P bit - the Proposal bit is used to indicate that this record is
a proposed group members record (here set to 1) or a current
group members record (discussed in the previous section).
o List of the Server IDs - this is a consecutive list of Server IDs
which comprise the sending server's view of the proposed SG mem-
bership. The Server IDs are IP addresses associated with one of
the server's interfaces.
DISCUSSION:
This record contains the proposed group membership from the
view of the proposing server. This record conceptually has a
temporary lifetime associated with the period for which a
group join proposal can live. If a server receives a SG COM-
MIT CHANGE UPDATE message, then this record becomes the new SG
Members record. If a SG COMMIT CHANGE UPDATE message is not
received within the appropriate period, then this record
expires. If the server receives a second SG PROPOSE CHANGE
UPDATE message while another Proposed Members record is
active, it should NAK this second Proposed Members record.
Only one group join can be in process at any given time.
8.5. Open Questions with the Mapping onto SCSP
The following questions are identified as outstanding issues to be
resolved for the CSAS and CSA record definitions to be considered
complete:
o SCSP is currently LLC/SNAP encapsulated. We are proposing that a
UDP port be defined to carry SCSP messages for DHCP. In fact we
are proposing that the entire DHCP interserver protocol be run
over UDP.
o SCSP has currently reserved its Protocol ID = 4 for DHCP. This
draft discusses DHCPv4 Interserver protocol and therefore the
SCSP Protocol ID reservation should reflect that fact. If a
DHCPv6 extension to this draft were developed it would require a
separate SCSP Protocol ID.
o SCSP dropped support for message fragmentation. We need to look
into the size required for the various records defined in this
draft and, if necessary, consider how to handle records larger
than can fit into a single UDP packet.
Kinnear, Cole & Droms [Page 72]
DRAFT July 1997
o Need to give further thought to the partitioning of the DHCP
interserver protocol into three separate but related subproto-
cols; the Group Management, the Binding Management and the
Address Management subprotocols. Currently this draft has these
as separate subprotocols, with the Group Management subprotocol
run separate from the SCSP protocol and in fact on a different
UDP port as the SCSP protocol. The Group Management does however
share common message semantics and syntax with the SCSP messages
in order to simplify parsing the various messages associated with
the DHCP interserver protocol. The Binding Management and the
Address Management subprotocols are run on top of SCSP with a
single Protocol ID.
o We need to explicitly discuss the method used to authenticate the
DHCP Interserver protocol messages. Current thinking is to use
the SCSP authentication extensions. This should be investigated
and should be consistent with the 'Security Architecture for
DHCP' draft [8].
9. IP Address State Transitions
The possible states of an IP address were defined in Section 3.2.2,
and the state transition diagram appears there. The state transi-
tions though which an IP address can move were discussed implicitly
in Section 6 in the context of the receipt of DHCP messages from DHCP
clients. However, an explicit examination of the processing required
of a server by this protocol on each of the state transitions will
serve to highlight some important aspects of this protocol.
The IP address state transitions are handled in the following way:
o UNBINDABLE -> POLLING
When a server attempts to make a particular IP address BINDABLE,
it first moves that IP address into the POLLING state. Once in
this state, if queried about whether that IP address is UNBIND-
ABLE, the server will reply negatively.
o UNBINDABLE -> BOUND
When a server is removed from a server group, all of the IP
addresses must be scanned to see if any of them show that server
as the server who performed the last transaction (as set by that
server successfully completing a CLIENT BINDING COMPLETE PUSH).
For all of those IP addresses, if there is a client recorded in
the IP address, and if that client does not have a currently dif-
ferent binding, then that IP address must be set to BOUND and the
lease time must be reset to the value sent in the latest CLIENT
Kinnear, Cole & Droms [Page 73]
DRAFT July 1997
BINDING COMPLETE PUSH.
The only states from which this transition will be made are
UNBINDABLE and EXPIRED.
o POLLING -> BINDABLE
A fundamental point and guarantee of this state transition dia-
gram is that for an IP address to move from the UNBINDABLE state
(where it is not owned by any server) through the POLLING state
and on to the BINDABLE state (where it is owned by a single
server) requires the server seeking to own the IP address to con-
tact all of the other servers in the group. It requires an
UNBINDABLE COMPLETE POLL to complete successfully.
The server attempting to move an IP address from the UNBINDABLE
through the POLLING and on to the BINDABLE state must ask every
other server in the group if it believes that the IP address is
currently UNBINDABLE using an UNBINDABLE COMPLETE POLL. If any
server says that the IP address is either BINDABLE (i.e., it cur-
rently owns the IP address) or BOUND (i.e., a client currently
owns the IP address), then the server attempting to move the IP
address from the UNBINDABLE to BINDABLE state MUST abandon the
attempt. If any server fails to respond at all, the server MUST
abandon the attempt as well.
DISCUSSION:
In addition (and this is important!) if the server attempting
to move the IP address from the UNBINDABLE state through the
POLLING state and on to the BINDABLE state fails to hear from
some other server, then the attempt cannot complete. This
means that if a server cannot communicate with every other
server (due to communications failure, transient server fail-
ure, or network partition) then this state transition cannot
be made.
Thus, all addresses in the UNBINDABLE state will stay in that
state while any server in the group is out of communication with
the group for any reason at all.
Of course, the detailed description of the protocol suggests that
a server build up a supply of BINDABLE IP addresses so that in
the event of server failure it has BINDABLE addresses that are
available to offer to new DHCP clients.
o BINDABLE -> BOUND
Kinnear, Cole & Droms [Page 74]
DRAFT July 1997
Once an IP address is BINDABLE it may be BOUND to a client
through the normal actions of the DHCP protocol. Once a server
has received a DHCPREQUEST/SELECTING message from a client it can
move the IP address into the BOUND state, update its stable stor-
age, and reply with a DHCPACK message to the client.
After the DHCPACK has been sent, the DHCP server MUST also
attempt to update all servers in the group with information indi-
cating that the IP address is now BOUND to a particular client.
It must perform a CLIENT BINDING COMPLETE PUSH operation with
this information.
An IP address that is BOUND will always result in a lease time
that is no greater than the MAXIMUM-UNPUSHED-LEASE-TIME when
given to a client, although the normal lease time is used in all
interactions with other servers.
DISCUSSION:
In an ideal world, the server who created the binding would
always succeed in updating all other servers in the group with
the binding information. Then, in the event that the binding
server failed at some later time, another server to whom the
client could broadcast would receive a DHCPREQUEST/REBINDING
request and could reply with updated binding information.
However, there is obviously a window where a server can crash
after sending a DHCPACK and prior to updating even one addi-
tional server. This protocol has been designed so that not
only is the process of updating all of the servers in the
group with information concerning a new binding "lazy" (i.e.,
performed after the actual binding is made), but also unneces-
sary for correct operation. The protocol only requires that a
server try to update the other servers -- not that it succeed
at updating even one server.
The protocol accomplishes this by allowing a server to respond
to a DHCPREQUEST/REBINDING message from a client without any
information having been propagated from the server who created
the binding. Thus, a server who receives a rebinding request
for an IP address about which it has no information must check
with all available servers in the group, but in the absence of
information to the contrary arriving within a relatively short
timeout period, the server should respond to the rebinding
request with an extension of the existing lease on the IP
address.
Kinnear, Cole & Droms [Page 75]
DRAFT July 1997
o BINDABLE -> UNBINDABLE
A server can relinquish an IP address in the BINDABLE state that
it owns simply by responding to requests for information about
the IP address as if it were UNBINDABLE. No explicit action need
be taken other than to respond correctly to POLL operations from
other servers.
o BOUND -> PUSHED
Once an IP address that is BOUND to a client has a CLIENT BINDING
COMPLETE PUSH succeed (and that means succeed to all of the
servers), then it moves from the BOUND to the PUSHED state. At
this point, the normal lease time may be returned to the client
on the next renewal or discover or rebinding.
Note that only the server which executes the CLIENT BINDING COM-
PLETE PUSH will set its IP address into the PUSHED state. The
state that it PUSHes to the other servers is BOUND.
o BOUND -> UNBINDABLE
In order for an IP address to move from the BOUND to the UNBIND-
ABLE state, the client that owns the IP address (i.e., to which
it is BOUND) must send a DHCPRELEASE message. In this case, the
receiving server (which may or may not be the server who created
original binding) will update its stable storage with information
that the IP address is not currently BOUND by any client. It
should then transmit this information to all other servers to
which it can communicate at that time by performing a CLIENT
BINDING COMPLETE PUSH operation.
In the event that the server fails to update any other server
with the new information about the IP address prior to undergoing
some failure, then the worst that will happen is that the other
servers will believe that an IP address is in the BOUND state
when it need not be. Ultimately the lease on the IP address will
expire.
o BOUND -> EXPIRED
Any server which has information concerning a BOUND IP address
may determine that the lease on the IP address has expired, and
after an appropriate grace period has elapsed, that the IP
address should be moved to the EXPIRED state. A record of the
client to which the IP address was BOUND must be kept.
Kinnear, Cole & Droms [Page 76]
DRAFT July 1997
o PUSHED -> UNBINDABLE
In order for an IP address to move from the PUSHED to the UNBIND-
ABLE state, the client that owns the IP address (i.e., to which
it is BOUND) must send a DHCPRELEASE message. In this case, the
receiving server (which may or may not be the server who created
original binding) will update its stable storage with information
that the IP address is not currently BOUND by any client. It
should then transmit this information to all other servers to
which it can communicate at that time by performing a CLIENT
BINDING COMPLETE PUSH operation.
In the event that the server fails to update any other server
with the new information about the IP address prior to undergoing
some failure, then the worst that will happen is that the other
servers will believe that an IP address is in the PUSHED state
when it need not be. Ultimately the lease on the IP address will
expire.
o PUSHED -> EXPIRED
Any server which has information concerning a PUSHED IP address
may determine that the lease on the IP address has expired, and
after an appropriate grace period has elapsed, that the IP
address should be moved to the EXPIRED state. A record of the
client to which the IP address was PUSHED must be kept.
o EXPIRED -> UNBINDABLE
If any server asks for information concerning this IP address,
then the receiving server should set the IP address to be UNBIND-
ABLE, update its stable storage, and respond to the requesting
server.
o EXPIRED -> BOUND
If a server receives a message from a client and the IP address
is EXPIRED, but was last BOUND or PUSHED to that client, then the
IP address can be moved back into the BOUND state. This is pos-
sible because no other server can have attempted to make this IP
address BINDABLE. If it had, the IP address would not be in the
EXPIRED state anymore, but in the UNBINDABLE state (see the
EXPIRED -> UNBINDABLE transition above).
Another reason this transition can occur is as follows. When a
server is removed from a server group, all of the IP addresses
must be scanned to see if any of them show that server as the
server who performed the last transaction (as set by that server
Kinnear, Cole & Droms [Page 77]
DRAFT July 1997
successfully completing a CLIENT BINDING COMPLETE PUSH). For all
of those IP addresses, if there is a client recorded in the IP
address, and if that client does not have a currently different
binding, then that IP address must be set to BOUND and the lease
time must be reset to the value sent in the latest CLIENT BINDING
COMPLETE PUSH.
The only states from which this transition will be made are
UNBINDABLE and EXPIRED.
10. Security Considerations
Minimal security would be provided by configuring every server in a
group with the IP addresses of the allowable servers that could ever
join that group.
Some additional security is created by using the SCSP security mecha-
nism, although there are limitations to that for other than the
client binding management part of the protocol.
Other, more powerful security approaches are and must be addressed
prior to further progress on this protocol.
11. Open Questions
The following open questions set off by the "*" character remain from
Ralph Droms' original draft: draft-ietf-dhc-interserver-00.txt.
Comments have been added in square brackets []. Additional open
questions new to this draft are listed with the "o" character.
* Each server must know all other servers.
Requiring each server to know about every other server imposes
additional administrative overhead in the configuration of DHCP
servers. However, this configuration overhead is probably mini-
mal relative to any other configuration required for DHCP
servers.
[The group management messages in Section 7 provide a step
towards an answer here. A server needs to know only one other
server.]
* Each server must contact all other servers before reassigning an
address.
Kinnear, Cole & Droms [Page 78]
DRAFT July 1997
[This is fundamental if we wish to use the "lazy synchronization"
mode -- you can't get one without the other.]
There is a potential issue here in which no new DHCP clients can
be configured if any of the DHCP servers cannot be contacted.
Servers can mitigate this problem by maintaining a list of pre-
checked addresses that can be allocated without contacting all
other servers at the time of address allocation.
The protocol may need additional definition of specific actions
on the part of DHCP servers in response to situations in which a
server cannot contact all other servers. [Added a lot of these
in this draft.]
* Servers cooperating to achieve "fair" distribution of available
addresses.
The protocol may need additional mechanisms or definition of
default behavior through which servers cooperate among themselves
to ensure that each has a sufficient pool of prechecked-addresses
on each network.
[Not yet addressed, and needs work. Initial thinking is that all
addresses should be allocated to some server, so that if the
event of a SG where one member can't be contacted, the maximum
addresses are available for TRANSFER operations as necessary.]
* User intervention in case of database incoherency.
Fixing the collective database on the DHCP servers in case of a
problem could be a *real* nightmare.
* Potential deadlock in checking address - suppose two servers
check the same address for reassignment simultaneously?
[Solved with the introduction of the POLLING state.]
* Potential configuration for new server?
One ancillary use of the inter-server protocol might be in con-
figuring new DHCP servers. Suppose the inter-server protocol
were extended to allow download of a server's configuration file
and to allow addition of a new server to the list of DHCP
servers. A new server might be configured by simply giving it
the address of an existing server. The new server could then
download a list of all other known servers, the pool of candidate
addresses, any special configuration information (e.g., vendor
class information) and the existing bindings. The new server
Kinnear, Cole & Droms [Page 79]
DRAFT July 1997
could also announce itself to all of the other existing servers.
[Much of this is in the current draft, principally in the group
management configuration messages. At this stage, a server can
figure out which groups correspond with which subnets, which
addresses that group manages on that subnet, and some additional
configuration information. This is considerable distance towards
both ensuring that all servers in the SG have compatible configu-
rations, as well as towards one server downloading configuration
data from another server.
Downloading configuration files would not be a great idea for
servers which don't use configuration files.]
* DHCP server maintenance
There is likely an opportunity for the development of a server
management tool that would download the database information from
all servers and check for conflicts/inconsistencies such as
assignment of an IP address to multiple clients, bindings that
are not replicated across all servers, bindings that have incon-
sistent lease expiration times, etc.
o Group-id selection.
The group-id's for various groups need to be sufficiently unique
that no server will ever be a member of two groups with the same
group-id. No mechanism is provided yet in this protocol to gen-
erate group-id's which conform to this requirement.
Possibly a group-id can be synthesized in some manner to ensure
that they conform to this requirement.
o The original draft discussed the requirement for each server to
have a synchronized clock using available time synchronization
protocols. That requirement has been removed in this draft, and
in its place all times are sent in "seconds from now" as a signed
32 bit number. There is clearly a bit of additional complexity
required to do this, but we have been so impressed at how well
DHCP works with "relative" instead of "absolute" time that we
felt the complexity of using relative time worth it (since using
synchronized time is not without its own complexities).
o UNAVAILABLE IP addresses
There are several cases where a server can determine that some
sort of serious error has occurred, and apparently an IP address
is in an inconsistent state. In these cases, the server should
Kinnear, Cole & Droms [Page 80]
DRAFT July 1997
make the IP address UNAVAILABLE -- i.e., no other server should
be able to operate on it. Just what is necessary to make this
happen? Could it be a passive response to address information
messages, or must it involve a complete push to all of the other
servers, and a new IP address state?
12. Acknowledgments
Many of the ideas in this proposal are due to Jeff Mogul, Greg Min-
shall, Rob Stevens, Walt Wimer, Ted Lemon and the DHC working group.
Thanks to all who have contributed their ideas and participated in
the discussion of the inter-server protocol.
At American Internet, Brad Parker and Mark Stapp have been key con-
tributors to the design discussions that have resulted in our contri-
butions to the this draft. They have each invested many hours of
work in this protocol.
13. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2] Luciani, J., Armitage, G., Halpern, J., "Server Cache Synchro-
nization Protocol (SCSP)", draft-ietf-ion-scsp-01.txt.
[3] Moy, J. "OSPF Version 2", IETF RFC1247, July 1991.
[4] Luciani, J., "A Distributed NHRP Service Using SCSP", draft-
ietf-ion-scsp-nhrp-00.txt.
[5] Luciani, J., Fox, B., "A Distributed ATMARP Service Using
SCSP", draft-ietf-ion-scsp-atmarp-00.txt.
[6] Reynolds, J., Postel, J., "Assigned Numbers", Internet STD 2,
Internet RFC 1340, USC/Information Sciences Institute, July
1992.
[7] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", Internet RFC 2132, March 1997.
[8] Gudmundsson, Olafur, "Security Architecture for DHCP", draft-
ietf-dhc-security-arch-00.txt.
Kinnear, Cole & Droms [Page 81]
DRAFT July 1997
14. Author's information
Kim Kinnear
American Internet Corporation
4 Preston Ct.
Bedford, MA 01730-2334
Phone: (617) 276-4587
EMail: kinnear@american.com
Robert G. Cole
AT&T Laboratories
Managed Network Solutions Division
Rm. 3L-533
101 Crawfords Corner Road
Holmdel, NJ 07733
Phone: (908) 949-1950
EMail: rgc@qsun.att.com
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Kinnear, Cole & Droms [Page 82]
DRAFT July 1997
Appendix A: An Overview of SCSP
This appendix presents an overview of the SCSP protocol and supple-
ments Section 8.2 in the main text of this specification. For a com-
plete discussion of the SCSP protocol see [2].
This appendix is divided into three following sections on the SCSP
Hello, Cache Alignment and Cache Update subprotocols respectively.
The last section of this appendix presents a summary of the SCSP mes-
sage sets.
A.1 The SCSP "Hello" Sub-protocol Overview
The function of the SCSP "Hello" protocol is to monitor the status of
the LS to DCS connection. The LS must be configured with the
addresses of its DCSs. The protocol contains a 'Family ID' which
allows for the multiplexing of multiple protocol specific SCSP imple-
mentations to rely on a single Hello mechanism between each server
pair. For each DCS (whether the low level connection is point-to-
point or point-to-multipoint), the LS maintains an Hello Finite State
Machine (HFSM). The HFSM is shown in the figure below.
+---------------+
| |
+------->| DOWN |<-------+
| | | |
| +---------------+ |
| | ^ |
| | | |
| | | |
| | | |
| V | |
| +---------------+ |
| | | |
| | WAITING | |
| +--| |--+ |
| | +---------------+ | |
| | ^ ^ | |
| | | | | |
| V | | V |
+---------------+ +---------------+
| BIDIRECTION |---->| UNIDIRECTION |
| | | |
| CONNECTION |<----| CONNECTION |
+---------------+ +---------------+
Figure A.1-1 The Hello Finite State Machine
Kinnear, Cole & Droms [Page 83]
DRAFT July 1997
Key:
1: Link layer connection is established
2: Transition based upon the receipt of a Hello message (and
whether the LS ID is found in the Rec ID portion of the message
3: Hello Interval * Dead Factor exceeded
4: Loss of link layer connectivity
The LS to DCS connections are initialized into the down state. The
numbers in the figure refer to the actions discussed in the Key that
cause a transition in the HFSM (Note: These numbers didn't appear in
the original figure in [2], and are TBD). The Hello protocol employs
poll messages to monitor the status of the LS to DCS connections.
The Hello messages contain the ID s of the DCS s that the LS has
received a Hello message from. The LS' HFSM uses these ID s to
determine the status of the HFSM for each of the DCS s. Multiple DCS
ID s are present in order to support point-to-multipoint connections.
The messages also contain two fields; the Polling Interval and the
Dead Factor. The product of the Polling Interval and the Dead Factor
determines the length of time that the HFSM will hold open a connec-
tion without receiving a Hello from a peer DCS and transitioning the
HFSM for that DCS to the Wait state.
A.2 The SCSP "Cache Alignment" Sub-protocol
The Cache Alignment protocol supports the initial server cache syn-
chronization process of an LS with its DCSs. This process may occur
at initial boot time of the server, at reconnect time of the server
to the network, or other possible initialization or failure recovery
scenarios. Like the Hello protocol, the Cache Alignment (CA) proto-
col maintains a Cache Alignment Finite State Machine (CAFSM) for each
of its DCSs to monitor the status of its cache alignment. The figure
below shows the CAFSM and indicates some of the triggers that would
cause the state transitions to occur.
Kinnear, Cole & Droms [Page 84]
DRAFT July 1997
+------------+
| |
+--->| DOWN |
| | |
| +------------+
| |
| |
| V
| +------------+
| |Master/Slave|
|----| |<---+
| |Negotiation | |
| +------------+ |
| | |
| | |
| V |
| +------------+ |
| | Cache | |
|----| |----|
| | Summarize | |
| +------------+ |
| | |
| | |
| V |
| +------------+ |
| | Update | |
|----| |----|
| | Cache | |
| +------------+ |
| | |
| | |
| V |
| +------------+ |
| | | |
+----| Aligned |----+
| |
+------------+
Figure A.2-1 Cache Alignment Finite State Machine
Key:
1: When HFSM reaches Bi-directional state
Kinnear, Cole & Droms [Page 85]
DRAFT July 1997
2: HFSM transitions out of Bi-directional state
3: Master/Slave relationship is established
4: Once both LS and DCS exchange CA messages, both with O-bit set
to 0, then CRL is complete
5: E.g., Errored sequence number
6: Full cache update achieved
(Note: The key numbers don't appear in the figure in [2],a and are
TBD.)
Each of the CAFSMs is coupled with the respective HFSMs in the LS.
The CAFSM is initialized in the Down state. It transitions to the
Master/Slave Negotiation state when the corresponding HFSM transi-
tions to the Bi-Directional state. The CAFSM transitions back to
the Down state in the event that the corresponding HFSM transitions
out of the Bi-Directional state.
In the Master/Slave state the LS-DCS pair negotiate who is to be the
master of the connection during the cache alignment process. In the
Cache Summary state the LS/DCS pair exchange Client State Advertise-
ment Summary (CSAS) records within the CA messages. The servers use
these message exchanges to build a Client State Advertisement Request
List (CRL). The CRL indicates the portions of the respective server
caches that are out of alignment. The cache mis-alignment (as indi-
cated in the local CRL) is resolved in the Update Cache state where
the servers exchange full client state information in CSA records
within the CSU messages, only where mis-alignment occurs. Once the
CRL is resolved, the LS/DCS caches are aligned and the CAFSM transi-
tions to the Aligned state.
The protocol further defines the high-level syntax of a generic CA
message as discussed in a later section of this appendix.
A.3 The SCSP "Client State Update" Sub-protocol Overview
The purpose of the Client State Update (CSU) protocol is to provide a
capability to constantly update the server caches through asyn-
chronous CSU message exchanges. These updates are necessary because
the status of the clients are in constant flux. Unlike the other two
sub-protocols, the Client State Update protocol does not maintain a
separate finite state machine. Instead, the activity of this proto-
col is tied to the CAFSM.
Each CSU can contain zero or more Client State Advertisement records.
Kinnear, Cole & Droms [Page 86]
DRAFT July 1997
The LS may send and receive CSUs when the corresponding CAFSM is in
either the Aligned or the Cache Update states. The CSU protocol
defines both CSU requests and reply messages. As consistent through-
out the definition of the SCSP, the CSU protocol supports both point-
to-point and point-to-multipoint connections.
A.4 The SCSP Message Set Overview
The structure of the SCSP messages is a)a fixed length, generic
header, b) a SCSP message specific part header of variable length, c)
an fixed length, message field and d) zero, one or more SCSP message
specific records. This is shown in the following figure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | type | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Checksum | Start of Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCSP Message Specific part (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID Len | Recvr ID Len | No. of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCSP Message Specific Records (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4-1 SCSP Message Format
where
o Version - is the version of the SCSP protocol defined in [2]
o type - represents the SCSP message type, i.e., CA, Hello,
CSU_Req, CSU_Reply, and CSU_Solicit
o Packet Size -
Kinnear, Cole & Droms [Page 87]
DRAFT July 1997
The SCSP messages have identical syntax except for the 1) the SCSP
message specific part header and 2) the SCSP message specific part
record. The following table summarizes the content of these specific
parts:
Table A.4-1 SCSP Message Specific Parts
| Hello | CA | CSUS | CSU_Req | CSU_Reply
------------------------------------------------------------------------
| | | | |
SCSP mesg | hello int,|CSA Seq.No.| null | null | null
spec header | dead fac.,| | | |
| Family ID | | | |
------------------------------------------------------------------------
| | | | |
SCSP mesg |Additional |CSAS Rec. | CSAS Rec. | CSA Rec. | CSAS Rec.
spec record | Recvr ID | | | |
| records | | | |
The detailed formats of the various SCSP messages are given in [2].
However, two SCSP message specific records are of particular interest
to the development of the DHCP interserver specification. These are:
1) the CSAS record and 2) the CSA record. The CSAS record is defined
within the SCSP specification as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4-2 SCSP CSAS Record Format
See Section 8.4.1 for details.
Kinnear, Cole & Droms [Page 88]
DRAFT July 1997
The CSA record is defined within the SCSP specification as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client/Server Protocol Specific Part Cache Entry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.4-3 SCSP CSA Record Format
The CSA records for the DHCP interserver mapping to SCSP are defined
in Section 8.4.2.
[end of document <draft-ietf-dhc-interserver-02.txt>]
Kinnear, Cole & Droms [Page 89]
