draft-ietf-dhc-failover-07.txt

open source dhcp server client etc...

   applies to leases that were issued BEFORE entering PARTNER-DOWN. Once
   a server has entered PARTNER-DOWN and it leases out an address, it
   need not wait this time as long as it has never communicated with the
   partner since the lease was given out.

   The fundamental relationship on which much of the correctness of this
   protocol depends is that the lease expiration time known to a DHCP
   client MUST NOT be more than the maximum client lead time greater
   than the potential expiration time known to a server's partner.

   The remainder of this section makes the above fundamental relation-
   ship more explicit.

   This protocol requires a DHCP server to deal with several different
   lease intervals and places specific restrictions on their relation-
   ships. The purpose of these restrictions is to allow the other server
   in the pair to be able to make certain assumptions in the absence of
   an ability to communicate between servers.

   The different lease times are:

      o desired lease interval

        The desired lease interval is the lease interval that a DHCP
        server would like to give to a DHCP client in the absence of any
        restrictions imposed by the Failover protocol.  Its determina-
        tion is outside of the scope of this protocol. Typically this is
        the result of external configuration of a DHCP server.

      o actual lease interval

        The actual lease internal is the lease interval that a DHCP
        server gives out to a DHCP client in the dhcp-lease-time option
        of a DHCPACK packet.  It may be shorter than the desired client
        lease interval (as explained below).

      o potential lease interval

        The potential lease interval is the lease expiration interval
        the local server tells to its partner in the potential-
        expiration-time option of a BNDUPD message.



Droms, et. al.            Expires January 2001                 [Page 21]

Internet Draft           DHCP Failover Protocol               July 2000


      o acknowledged potential lease interval

        The acknowledged potential lease interval is the potential lease
        interval the partner server has most recently acknowledged in
        the potential-expiration-time option of a BNDACK message.

   The key restriction (and guarantee) that any server makes with
   respect to lease intervals is that the actual client lease interval
   never exceeds the acknowledged potential lease interval (if any) by
   more than a fixed amount.  This fixed amount is called the "Maximum
   Client Lead Time" (MCLT).

   The MCLT MAY be configurable on the primary server, but for correct
   server operation it MUST be the same and known to both the primary
   and secondary servers.  The secondary server determines the MCLT from
   the MCLT option sent from the primary server to the secondary server
   in the CONNECT message.

   A server MUST record in its stable storage both the actual lease
   interval and the most recently acknowledged potential lease interval
   for each IP address binding.  It is assumed that the desired client
   lease interval can be determined through techniques outside of the
   scope of this protocol.  See section 7.1.5 for more details concern-
   ing the times that the server MUST record in its stable storage and
   the way that they interact with the lease time that may be offered to
   a DHCP client.

   Again, the fundamental relationship among these times which MUST be
   maintained is:

       actual lease interval <
       ( acknowledged potential lease interval + MCLT )


   Figure 5.2.1-1 illustrates an initial lease to a client using the
   rules discussed in the example which follows it.  Note that this is
   only one example -- as long as the fundamental relationship is
   preserved, the actual times used could be quite different.













Droms, et. al.            Expires January 2001                 [Page 22]

Internet Draft           DHCP Failover Protocol               July 2000



              DHCP                 Primary             Secondary
       time   Client               Server               Server

                | (time in intervals) |  (absolute time)   |
                |                     |                    |
                | >-DHCPDISCOVER->    |                    |
                |     <---DHCPOFFER-< |                    |
                |                     |                    |
                | >-DHCPREQUEST->     |                    |
                |   (selecting)       |                    |
                |                     |                    |
         t      |  <--------DHCPACK-< |                    |
                |  lease-time=MCLT    |                    |
                |                     |    >-BNDUPD-->     |
                |                     |  lease-expiration=t+MCLT
                |                     |  potential-expiration=t+(MCLT/2)+X
                |                     |                    |
                |                     |     <-BNDACK-<     |
                |                     |  potential-expiration=t+(MCLT/2)+X
               ...                   ...                  ...
                |                     |                    |
      t+MCLT/2  | >-DHCPREQUEST->     |                    |
                |      (renew)        |                    |
                |                     |                    |
         t1     |  <--------DHCPACK-< |                    |
                |   lease-time=X      |                    |
                |                     |    >-BNDUPD-->     |
                |                     |  lease-expiration=t1+X
                |                     |  potential-expiration=t1+(X/2)+X
                |                     |                    |
                |                     |     <-BNDACK-<     |
                |                     |  potential-expiration=t1+(X/2)+X
               ...                   ...                  ...

           Figure 5.2.1-1:  Lazy Update Message Traffic
                          X = Desired Lease Interval
                          Assumes renewal interval = lease interval / 2


   DISCUSSION:

      This protocol mandates only that the above fundamental relation-
      ship concerning lease intervals is preserved.

      In the interests of clarity, however, let's examine a specific
      example.  The MCLT in this case is 1 hour.  The desired lease
      interval is 3 days, and its renewal time is half the lease



Droms, et. al.            Expires January 2001                 [Page 23]

Internet Draft           DHCP Failover Protocol               July 2000


      interval.

      The rules for this example are:

      o What to tell the client:

        Take the remainder of the acknowledged potential lease interval.
        If this is a new lease, then this value will be zero.  If this
        remainder plus the MCLT is greater than the desired lease inter-
        val, give the client the desired lease interval else give the
        client the remainder plus the MCLT.

      o What to tell the failover partner server:

        Take the renewal interval (typically half of the actual client
        lease interval), add to it the desired lease interval, and add
        it to the current time to yield the value that goes into the
        potential-expiration-time option.

        Also tell the failover partner the actual lease interval by
        adding it to the current time to yield the value that goes into
        the lease-expiration option.

      In operation this might work as follows:

      When a server makes an offer for a new lease on an IP address to a
      DHCP client, it determines the desired lease interval (in this
      case, 3 days).  It then examines the acknowledged potential lease
      interval (which in this case is zero) and determines the remainder
      of the time left to run, which is also zero.  To this it adds the
      MCLT.  Since the actual lease interval cannot be allowed to exceed
      the remainder of the current acknowledged potential lease interval
      plus the MCLT, the offer made to the client is for the remainder
      of the current acknowledged potential lease interval (i.e., zero)
      plus the MCLT.  Thus, the actual lease interval is 1 hour.

      Once the server has performed the BNDACK to the DHCP client, it
      will update the secondary server with the lease information. How-
      ever, the desired potential lease interval will be composed of the
      one half of the current actual lease interval added to the desired
      lease interval. Thus, the secondary server is updated with a
      BNDUPD with a lease interval of 3 days + 1/2 hour specified in the
      potential-expiration-time option.

      When the primary server receives an ACK to its update of the
      secondary server's (partner's) potential lease interval, it
      records that as the acknowledged potential lease interval.  A
      server MUST NOT send a BNDACK in response to a BNDUPD message



Droms, et. al.            Expires January 2001                 [Page 24]

Internet Draft           DHCP Failover Protocol               July 2000


      until it is sure that the information in the BNDUPD message
      resides in its stable storage.  Thus, the primary server in this
      case can be sure that the secondary server has recorded the poten-
      tial lease interval in its stable storage when the primary server
      receives a BNDACK message from the secondary server.

      When the DHCP client attempts to renew at T1 (approximately one
      half an hour from the start of the lease), the primary server
      again determines the desired lease interval, which is still 3
      days.  It then compares this with the remaining acknowledged
      potential lease interval (3 days + 1/2 hour) and adjusts for the
      time passed since the secondary was last updated (1/2 hour).  Thus
      the time remaining of the acknowledged potential lease interval is
      3 days.  Adding the MCLT to this yields 3 days plus 1 hour, which
      is more than the desired lease interval of 3 days.  So the client
      is renewed for the desired lease interval -- 3 days.

      When the primary DHCP server updates the secondary DHCP server
      after the DHCP client's renewal ACK is complete, it will calculate
      the desired potential lease interval as the T1 fraction of the
      actual client lease interval (1/2 of 3 days this time = 1.5 days).
      To this it will add the desired client lease interval of 3 days,
      yielding a total desired partner server lease interval of 4.5
      days.  In this way, the primary attempts to have the secondary
      always "lead" the client in its understanding of the client's
      lease interval so as to be able to always offer the client the
      desired client lease interval.

      Once the initial actual client lease interval of the MCLT is past,
      the protocol operates effectively like the DHCP protocol does
      today in its behavior concerning lease intervals. However, the
      guarantee that the actual client lease interval will never exceed
      the remaining acknowledged partner server lease interval by more
      than the MCLT allows full recovery from a variety of failures.

5.2.2.  Controlled re-allocation of IP addresses

   When in PARTNER-DOWN state there is a waiting period after which an
   IP address can be re-allocated to another client.  For leases which
   are available when the server enters PARTNER-DOWN state, the period
   is the MCLT from entry into PARTNER-DOWN state.  For IP addresses
   which are not available when the server enters PARTNER-DOWN state,
   the period is the MCLT after the lease becomes available.  See sec-
   tion 9.4.2 for more details.

   In any other state, a server cannot reallocate an address from one
   client to another without first notifying its partner (through a
   BNDUPD message) and receiving acknowledgement (through a BNDACK



Droms, et. al.            Expires January 2001                 [Page 25]

Internet Draft           DHCP Failover Protocol               July 2000


   message) that its partner is aware that that first client is not
   using the address.

   This could be modeled in the following way.  Though this specific
   implementation is in no way required, it may serve to better illus-
   trate the concept.

   An "av