Provisioning Server Enhancement 2
Patented improvements on enterprise and public DHCP servers

By: Bruce Bahlmann - Contributing Author (your feedback is important to us!)

Created: February 24, 1999

Note: For help designing your provisioning system or developing tools to help test, automate, and deploy your system contact Birds-Eye.Net.

Overview:

Existing IP address provisioning DHCP* servers geared for enterprise networking currently offer only minimum functionality need by operators of a Multiple Subscriber Organizations (MSO) cable modem systems. This document second in a series of provisioning server enhancement documents. The following is a list of feature enhancements that could be made by DHCP vendors to empower MSOs to deliver advanced services and increase operational efficiencies:

1. Client-based DHCP option configuration
2. Extending file/pathname creation using appending
3. Roaming DHCP leases

* Use of DHCP from here on out will also mean dynamic BOOTP

Each of these enhancements will be discussed in detail. The object of this document is to describe the business need as well as the possible results of adding this functionality that an MSO needs to diversify its one-size fits all product.

Discuss Individual Enhancements:

Client-Based Service Configuration

A particularly attractive feature for DHCP servers is to assign individual DHCP options by client or by service group. Some DHCP servers allow this low level of assignment however the means is usually limited either by functionality or scalability. An effective way to register a client would be to associate it with a service group and allow assignment of various other DHCP options based on their level of specificity. Ideally the service groups should be tiered to enable very particular (base level) DHCP options at the low level (for example bootfile name) and more global DHCP options to be set at the higher (parent) level. However, service groups are not designed for individuality. Individuality would require that a service group be created for each and every unique client – the number of service groups possible is limited by the number of service groups a DHCP server is possible of supporting.

The best way to handle individuality is to allow individual client configuration. Figure 1.0 shows how a client could be registered with specific DHCP options. This functionality would provide granular control of clients (individuality) yet still enabling clients to inherit additional DHCP options from any service groups, policies, and or subnets which it is associated. The combination of individual client and service group configuration provide an extremely flexible environment that would simplify follow-on technology (i.e. TFTP) to have to make complex decisions or look up in external data stores for the information that DHCP can now pass along in the response.

Figure 1.0 Client configuration

The level of specificity is important because a client can pick up DHCP options through various stages of the request processing. Figure 1.1 shows the process a client would go through if this functionality existed in a DHCP server. Note that the options defined initially (server global level) can be overwritten by anything that follows (DHCP options closest to the client have priority over options defined further from the client). However, any options uniquely defined in any phase of the assignment should trickle down the to final response handed to the client. In addition, any configurations set along this path can be reset to new configurations. For example if hd=/x/y in the subnet options, it can be reset to hd=/z/y (or even blanked out [hd=]) in the client options.

Figure 1.1 DHCP Options Assignment

Figure 1.2 shows how client-based configurations can take advantage of tiered service groups. In this example a client could be configured with a DHCP option (bf=300x300) and also with the Commercial service group that is a member of the parent service group of Affiliate A. The result of this would be that the client would receive a DHCP option bf=300x300 along with the DHCP options associated with the Commercial service group and as well as those associated with Affiliate A.

Figure 1.2 DHCP Options Assignment using client specific and service group configuration

The power of this level of configuration results in the highest degree of client configuration and customization and reduces the complexity of information that must be associated with a higher level object (such as a subnet, policy, or service group). Also note that since this data is usually stored elsewhere, the server performance is increased on the loading of subnets and policies because the client specific information is not related to any of these objects.

• Translated: cable modem assigned to network "cm" and userclass (or service group) "<none>" account no "m101001929" and individual client parameters "bf=300x300" (name of bootfile given to client) and group "tc=residential" (name of independent policy group client is associated with this client).

In terms of how this functionality is intended to work on any type of DHCP server, the following guidelines should addressed:

• The number of options supported should be limited ‘only’ by the number of characters the client-based options field will handle (suggested that field be no more than 60 characters). In other words, any DHCP option configurable in a subnet, policy, or client area be available for client configuration but the number of options allowed to set will be limited by what can be entered into the 60 character field.
• When options are entered into the field they will be truncated at 60 characters.
• Any option truncated will be read up to the last complete option (any option not ending with a colon ":" will be ignored).
• If these fields are farmed out to a LDAP server, the client fields will be named as they are represented in the standard bootptab format (i.e. "ha" for hardware address, "ip" for ip address, "ho" for hostname, "dn" for domain name, etc.) rather than be contained in a single character string. In other words, LDAP will support a full complement of DHCP options available as "possible" attributes for client-based configuration. A DHCP server looking up this client would receive this list of attributes and apply them as it would if they were joined in the 60 character string mentioned above. However, the LDAP version of this would not be restricted to 60 characters but rather how many attributes (DHCP options in this case) each record will support (if this configurable).

Extending File/Pathname Creation Using Appending

The whole idea of supporting devices that require both DHCP and an MD5 file (via TFTP) presents two different types of load on the database that stores client configurations. One can argue that centralizing configurations for DHCP and TFTP on a single server provides "relatively" efficient means of supporting customized services. However, the load that is generated as a result may not be sustainable as subscribers increase because the ability for an MD5 file to be created depends on a successful query to the centralized database. If that database is under increased load the response may not come back in time to satisfy the client’s time requirements for the TFTP server to build and respond to its MD5 file demands. A more attractive way to generate MD5 files for these devices is to provide as many (if not all) client specific parameters in the file/pathname so as to eliminate the need for the TFTP server to obtain more information (thus reducing the load on the client configuration database). A more in-depth explanation of this kind of TFTP server is covered in a separate document.

If the TFTP server is given all the parameters it needs to build semi-individualized MD5 file, the percentage of time this server must request this information from the client database is greatly reduced (perhaps less than 5% of all clients would require additional information that will not fit into the space allowed in the file/pathname field). For this "small" percentage of clients its more reasonable to ask that the TFTP server be able to query externally for this type of information it needs to build the requested MD5 file. Additional functionality in the TFTP server caches the client configuration database query for some finite amount of time until the either the client is responded or the entry times out. For the remaining clients, the file/pathname encoded parameters passed to TFTP "must" accommodate semi-individualized parameters to create their MD5 file on-the-fly.

To accomplish this semi-individualized behavior, DHCP "must" be able to run in two modes (substitute [default/normal] and append). The concept behind having these two modes is to leverage functionality already in DHCP servers by allowing for highly customized assembling of the file/pathname parameters before they are sent to the client. This is accomplished by allowing the file/pathname parameters to either be replaced or appended while the server processes a valid client request. The following provides some rules that would allow this functionality to coexist with existing DHCP server functionality:

• Existing filename (bf) and home directory (dh, hd) assignment for DHCP and BOOTP transactions are grandfathered (i.e. replacement is assumed when a "typical" assignment is encountered such as :hd=/DOCSIS: which resets the home directory DHCP option to a value of "/DOCSIS").
• Successive replacements of file/pathname variables (bf, hd, dh) result with which ever value was replaced last. For example if bf is set to "basic" in the subnet DHCP options, but later replaced with "headend" in the client-based configuration, the resulting value of bf will be "headend".
• Append mode is entered when ever file/pathname variables are assigned values that begin with a dot ("."). Any file/pathname that does not begin with a dot will be interpreted as a replacement operation.
• Values that are interpreted as append, will be tacked-on (appended) to the end of the existing value of its associated variable. For example, if hd was assigned a value of /DOCSIS (hd=/DOCSIS) in some policy and was later assigned a value of "./ldap" (hd=./ldap), the resulting value of hd would be /DOCSIS/ldap.
• Any replacement that follows an appending operation can over-ride the value just as any appending operation can modify a previous replacement.
• An append operation that follows an undefined replacement operation (i.e. hd that has not been previously set) or a reset operation (i.e. [hd=]) will be treated the same as an assignment operation since the variable be appended to has no previous value.
• Replacement and appending operations will follow the flow of generalized to specific such as that if Figure 1.1. In other words, client based parameters will be able to replace or append to previously set parameters such as those set by server defaults or subnets. Its important to note that if the order of these options may be a factor unless these values are set in terms of key value pairs (i.e. bf=basic). If key value pairs cannot be utilized, the order of the parameters stored in the file/pathname field must be consistent and in sync with what the TFTP server is expecting.

The append/replacement functionality allows a DHCP server to capitalize on its hierarchical relationships and allow more precise assignment file/pathname parameters to be passed on to the TFTP server with little modification to the DHCP server.

Roaming DHCP leases

Providing wide area network DHCP services has the ability to provide functionality called "roaming". A "type" of roaming is provided in most common DHCP servers today, for example auto-release. Auto-release essentially allows a client who has joined a new DHCP subnet to receive a new lease on that subnet while releasing its previous lease. A desirable feature of auto-release is to enable clients who have moved subnets (roamed) to recover their released lease when/if they return to their previous subnet. The problem with "existing" features such as auto-release is that it breaks a one-lease-per-client model that is required by troubleshooting systems to located active clients across the network. If a single client holds multiple leases on the network, one would have to look more closely at the lease (compare time parameters of each lease to determine which one is more current). Note that other variations of auto-release exist that result in the permanent removal of the previous lease such that on-lease-per-client is maintained only, when the client returns to its previous subnet, it is "unlikely" to get back its old lease using this variation.

Before explaining a method for supporting roaming leases, its important to understand why its desirable to support such functionality. Considering the case where a DHCP server is supporting a wide area network and this network penetrates many businesses and public places the ability to "plug-in" is highly desirable. With the proliferation of laptops, telecommuting, etc. customers will come to expect more from their ISP: like the ability to go to the library and plug their laptop in to do research for work. Or plug-in at the auto-repair shop while waiting for their car to get fixed. Providing such "expanded" connectivity enables "public" high-speed ethernet connectivity to be more than just an at home connection, but rather more like a public accessible resource. If a client roams (for example from home to the library and back to home) and this client does not get back its previous lease, the result "might" be that the client can no longer log into protected systems that are programmed with the client’s IP address. Although using DHCP inherently will force similar hardship on clients when the network inevitably expands (process called renumbering that re-distributes DHCP IP addresses among heavily populated subnets in order to make more available for further network expansion), these events are well communicated to subscribers who can prepare for the event. If roaming causes a "sudo" renumbering this will likely break any systems pre-programmed with the client’s IP address and thus cause hardship because it was unannounced.

The "best" way to provide roaming would be to satisfy the following requirements:

• For troubleshooting purposes, one-lease-per-client MUST be maintained so that when the client is looked up in a list of IP addresses the "one" (only one) that returns is that device’s correct IP address.
• One lease per client means one lease period. The lease in this case can be active, or expired but only one lease is present (i.e. a client cannot have both a active and an expired lease).
• An expired lease must represent one and only one case. That case being a client who has failed to renew its lease before its expiration date and as a result has become expired.
• Allow for clients that are "active" (i.e. still utilizing the IP address – lease) however for some reason or other have not requested a renewal from the server to renew/refresh the lease. In this case, expired does not mean deactivated but rather inactive.
• Allow clients who have roamed and returned, to get back their old IP address lease upon returning.

 To provide this it is proposed that a third lease state is created! In this state, the lease is actually the "first" available in the event the dynamic pool is full (so as not to disrupt the standard DHCP behavior). However, the lease does not show up as an "expired" lease (because its not) and will not be displayed in a standard lease dump. If a client who has a lease on some subnet and moves to a new subnet its existing lease takes on this state (call it "inactive"), and receives a new lease on the subnet which it now resides. Its previous lease remains "ear-marked" for this client because its mac address is still associated with it. If that client ever does "roam" back to that subnet, its existing lease will become "inactive" and (if the subnet has not become full) it will receive its old lease back. If its old subnet is full (or over-run its available pool), and its current lease has not yet been taken by new clients it gets its old lease back, however if its old lease does not exist, it just receives a new lease (one previously inactive [if any exist] or else the "oldest" expired lease).

Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white papers hot off the presses by adding our RSS feed to your reader.

(C) Copyright Birds-Eye.Net, All rights reserved.
It is against the law to reproduce this content or any portion of it in any form without the explicit written permission of Birds-Eye Network Services, LLC. Federal copyright law (17 USC 504) makes it illegal, punishable with fines up to $100,000 per violation plus attorney's fees.