====== Overview ======

We definitely live in an IP world, and IPv4 is still alive. More and more devices are connected to the Internet or to ISP private infrastructure. Each device needs to be delivered an IP address before being usable, stressing more and more demanding needs on DHCP infrastructure.

DHCP was originally designed for Local Area Networks (LAN) to manage tens or hundreds of computers and IP addresses. It is now common for an ISP to manage millions or tens of millions of customers on central infrastructures. DHCP needs to follow this trend and to be able to bring carrier-grade solutions to IP addresses distribution.

This is were DHCP Cluster was born. Its goals are to provide (in this order of priority):

  * **Reliability** (mainly through high availability)
  * **Extendability** (being able to adapt to specific contexts)
  * **Performance** (and Scalability obviously)
  * **Simplicity**
Note: DHCP Cluster is targeted to small networks LAN DHCP Server as well as large scale ISP solutions.

It is available in two flavours:

  * **Basic**: all in one solution, very simple to install and manage, powerful, single-server
  * **Extended**: (coming soon) multi-server with high availability database, very high performance, large network topologies








===== History (2004-2007) =====

In 2004 working in France Telecom, we were looking for a robust high performance DHCP server suitable for an xDSL IPTV solution. There was an existing prototype developped on an ISC dhcpd base, but it proved to be very hard to maintain and to plug to an existing Oracle database.

At that time, the DHCP algorithm was very simple. Each client had a fixed address depending on line-ID in the DSLAM marked via the option-82. This simple algorithm would calculate the client address then update the Oracle database to mark the client as connected. ISC dhpcd was absolutely not suited for such an "algorithmic" address alocation.

I have already believed that DHCP was a simple protocol and that developing a industrial-strength server solution was not so difficult. My thoughts were quickly confirmed.

And yet, we did not find any suitable solutions at that time. So I decided to develop a simple prototype in Perl to check the faisability. A few weeks later it was ready and gave excellent results. At the same time, I revived the Perl module [[http://search.cpan.org/~shadinger/Net-DHCP/|Net::DHCP]] to offer a full DHCP API.

The full server was then industrialized by a small project team and eventually put into production by end 2004. Performance was still quite high despite the interprative nature of Perl, resulting in more than 600rq/s on a standard Xeon 3.2GHz server.

Note: the module Net::DHCP is not very active anymore but I still do some bug correction from time to time. The active version is the Java one - dhcp4java.

The IPTV service evolved to a more classical dynamic addresses allocation mecanism. We had lots of discussion about what would be the best software architecture with internal R&D people, and this is where the dhcpd-j architecture came into life. It is basically a transposition of the classical Web architecture - application frontend / Database persistant store.

We first plugged the Perl front-end to an Oracle database. It shortly became obvious that we had to share our developments with a broader community of people in the company, and Perl was not the most easily readable and sharable code. I decided to switch to Java. The good news at that time was that the Java version was nearly 10x faster than the Perl version (which was already not so bad).

This is were **dhcpd-j** began, first as a Java port of Net::DHCP, then as a richer and more complet DHCP Api.

At that point we decided to share our dhcpd-j developments with the open-source community to deploy more widely this solution and benefit from your enhancements. Some people of the R&D teams also decided to create a spin-off around this development (and some others), we wish them a big success.

Starting from that point, the solution evolved in the two different flavours:

  - **Basic** which I will continue to maintain and evolve as a all-in-one product, simple and easy to configure and run,
  - **Extended** which provides higher performance and high availabiliy, thus requiring a separate databse installation. The core product will be kept in open-source. We might provide some productivity ad-hoc tools and some support as a commmercial offering.

<style right>
//Stephan Hadinger//
</style>



===== Credits =====

First PERL version (without database) was developed by: Bruno Crane, Stephan Hadinger with huge support from Eric Bottarlini, Pierre-Yves Eymard, Laurent Gaillard.

Second PERL version (with database) was developed by: Bruno Crane, Pierre Fischer (Oracle dev)<hi>anyone else?</hi>. Architecture and global design made by François Bourdaix ans his team.

Java port by: Bruno Crane, Stephan Hadinger. Many thanks to all people cited above who did a tremendous work on this project.