The DHCP Failover Protocol A Formal Perspective

1. The DHCP Failover ProtocolA Formal Perspective Rui Fan MIT Ralph Droms Cisco Systems Nancy Griffeth CUNY Nancy Lynch MIT

2. Fault Tolerant DHCP • Dynamic Host Configuration Protocol (DHCP) is a widely deployed protocol to assign IP addresses and other client parameters. • DHCP is also important for the wireless and mobile setting. • Current implementations use one DHCP server, are not fault tolerant. • Main challenge to using multiple servers is to maintain consistent view of assigned addresses across servers to avoid double allocation. • Standard database techniques are too slow. • The DHCP Failover Protocol (DKS+’03) is a 2-server DHCP algorithm retaining the clientinterface and performance of DHCP.

3. Our Contributions • We present an algorithm based on DKS+’03, generalized to arbitrary number of servers. • Rigorously specify algorithm and its behavior using TIOA • Helps end-users understand and use DHCP. • We decompose the DHCPF problem into independent subproblems. • Subproblems can be solved separately, and their solutions composed to solve DHCPF. • Helps to understand and prove the correctness of the algorithm. • Helps to analyze the effects of network parameters on algorithm performance, and to optimize the algorithm. • Demonstrates that formal, theoretical approach can provide correct, simple and efficient solutions to complex, real-world problems.

4. Timed I/O Automaton • Formal modeling framework for describing distributed systems. • Rigorous and structured. • Composition, simulation, other proof / design techniques. • A Timed I/O Automaton (TIOA) [KLSV’05] consists of • States, start states • Discrete actions State transitions (state, action, state) • Continuous actions (trajectories) A mapping from [0,t] to states • Scheduling of actions is nondeterministic. • Execution is alternating sequence of trajectories and discrete actions. • Example A mobile robot. • State is its position. • Discrete actions are changes in destination. • Trajectories are movement towards destination.

5. System Assumptions • Ideally, we want DHCPF to satisfy the following. • Safety property No IP address is double allocated. • Liveness property All client commands are quickly executed. • These properties depend on correct behavior of network and environment. • Clock assumption • Clients and servers have bounded skew clocks. • Let D be a constant. Then |clocki(t) – t| £ D, for every client or server i, and every time t. • Both safety and liveness depend on clock assumption.

6. System Assumptions • Stability • Let l be a parameter. A time interval [t, t’] is l-stable if • Some server is alive throughout [t-l, t’]. • No server fails or recovers during [t-l, t’]. • Timeliness • Time interval [t, t’] is l-timely if any message sent during [t, t’-l] is delivered within l time. • Liveness property depends on having sufficiently long stable and timely time intervals.

7. System Assumptions • Failure detector U • U tells servers which other servers are alive. • Model by recvU,j(ádead, j’ñ) andrecvU,j(áalive, j’ñ) actions, where j, j’ are servers. • Can be implemented by heartbeats, network admin, etc. • Let n be a parameter. U is n–perfect if it satisfies • Accuracy If recvU,*(ádead, j’ñ) occurs at time t, then j’ is dead sometime in [t-n, t]. Likewise for recvU,*(áalive, j’ñ). • Timeliness Every j gets a recvU,j(ádead, j’ñ) or recvU,j(áalive, j’ñ) msg every n seconds, for every j’. • Failure detectors used in many distributed algorithms, and are sometimes provably necessary. • Safety depends on a failure detectorU.

8. server client bcast(discover,k) send(offer,k,f) send(ack,k,f,t’) bcast(request,k,f,t) bcast(renew,k,f,t’’,t’) send(ack,k,f,t’’’) A Formal Spec of DHCPF • DHCP client interface and message exchange sequence. • k is an interaction identifier. • Client is correct if it executes this message sequence. • Say client i owns an IP address f at time t if send*,i(ack,*,f,t) occurs before t, and t³ t – D. • Takes into account clock skew of client. • If i doesn’t own f at t, then i is definitely not usingf at t. • Assumes correct clients.

9. A Formal Spec of DHCPF • Assume a n-perfect failure detector, and a D bound on clock skew. • Safety For all IP addresses f and at all times t, at most one client owns f at t. • Request liveness Suppose time t is (4n+4D)-stable and d-timely, and client i does bcast(discover,k) at time t. Assume client i is correct and does not fail during [t, t+4d]. Then • By time t+d, every live server receives i’s message. • By time t+2d, either send(offer,k,f) occurs for some f, or for every f, either • f was offer’ed to some client but not request’ed. • There is a lease for f which has not expired. • If send(offer,k,*) occurs, then send(ack,k,*,*) occurs by time t+4d.

10. A Formal Spec of DHCPF • Renew liveness Suppose time t is (4n+4D)-stable and d-timely, and client i has a lease for f for time ³ t+d+D. Then if i bcasts renew for f at t, i recvs an ack for f by time t+2d.

11. DHCPF Algorithm Overview • We break the DHCPF problem into two independent subproblems, Lease and Elect. • Elect • For any IP address f, elect a leader server for f. • Only the leader can lease f to clients. • There is at most one leader for f at any time. • The leader can change as servers fail and recover. • Lease • The leader gives out leases for f. • Ensure clients can always request or renew leases for f. • Ensure no double allocation even if leader changes. • Lease and Elect run continuously, in parallel. • The DHCPF algorithm is the formal composition Elect ´ Lease.

12. The Elect Algorithm • For any IP address f, Elect ensures • Safety There is at most one leader server for f at any time. • Liveness If execution is currently “nice”, then a leader exists. • Code shown is for server j. • clock The current clock value at j. • live Set of servers j thinks is alive. • my-addrsSet of IP addresses j thinks it is leader for. • lead-time[f]Time when j became leader for f. • rec-timeTime when j last recovered.

13. is min, and enough time passed no longer min The Elect Algorithm • Basic idea is the min live server should be leader for f’s. • Actually, can use a different minf for each f, for load balancing. • If j hears j’ is alive • Add j’ to live. • For each f, if j no longer minf for f, give up leadership of f. • If j hears j’ is dead • Remove j’ from live. • For each f, if j became minf for f, and enough time passed since last recovery, become leader for f. • Time to wait depends on quality of failure detector n, and clock skew D.

14. s1, s2 both leaders for f s1 is alive from this point on n n s1 dead alive s2 s2 sees s1, won’t become leader t-2n t-n t Elect Properties • Assume U is n-perfect, and clock skew is at most D. • Theorem(Safety) At any time, for any address f, there is at most one server j with fÎmy-addrsj. • Proof • Theorem (Liveness) If current state is (4n + 4D)-stable, then for every address f, we have fÎmy-addrsminfL, where L is the set of current live servers.

15. s1 s2 req(10) 1 ok(4) lease(10) 2 ack(10) 3 renew(15) 4 ok(10) lease(15) 5 ack(15) renew(20) 10 ok(15) lease(20) The Lease Algorithm • To avoid double allocation, leader should tell others servers its leases, in case it fails. • Waiting for acks from other servers is too slow. • Leader first gives client a temporary Maximum Client Lead Time (MCLT) lease. • Client gets a shorter lease than he asked for. • While client is using MCLT lease, leader negotiates an acknowledged lease with other servers. • When client renews, he gets the lease he asked for last time. • In this example, suppose MCLT = 3.

16. s1 s2 req(10) 1 ok(4) lease(10) 2 req(8) ack(10) 3 nok 4 5 The Lease Algorithm • When new leader takes over, it waits MCLT time, and also till its max acknowledged lease expires. • This upper bounds the maximumpotential lease that the previous leader might have given out. • Leader only gives out new lease for f when all potential leases have expired. • This is the main idea of DKS+’03.

17. wait for max of MCLT and potlease give the ack’ed lease check f is available MCLT lease negotiate acknowledged lease every server increased potlease, so j can increase acklease The Lease Algorithm • potlease[f] Maximum potential lease given out for f. • reserved Set of addresses offered but not requested. • acklease[f] The lease value that j will give for f. • kAn interaction identifier. • write-acks[k] Set of servers acknowledging interaction instance k.

18. Safety of Elect ´ Lease • TheoremElect ´ Lease satisfies the safety property of the DHCPF specification. • Proof A sequence of invariants, proved by induction on the execution. • Prove that servers have good estimate of max lease given out for f. • Lemma For all j, j’, if jÎwrite-acks[k]j’, then potlease[fk]j ³ tk • Lemma For all j, j’, max(potlease[f]j, clockj + MCLT + 2D) ³acklease[f]j’ • Key invariant of [DKS+’03]. • Only consider actions s which increase acklease[f]j’.

19. Safety of Elect ´ Lease • Lemma Let W be the leader for f. Then potlease[f]W³acklease[f]j, for all j. • If inductive stepdoesn’t change leader, we show this using the fact that there’s at most one leader for f. • If leader changes, then W sets potlease[f]W¬max(potlease[f]j, clockj + MCLT + 2D). • Since leader always knows the max lease for f, it avoids double allocation during request or renew.

20. Liveness of Elect ´ Lease • Hard to state • Need to identify all situations which prevent progress. • Easy to prove! • When nothing bad happens, something good happens. • TheoremElect ´ Lease satisfies the request and renew liveness properties of the DHCPF specification. • Proof (Request liveness) • Suppose client i bcasts discover at time t. By time t+d, every live server gets i’s message. • Since t is (4n + 4D)-stable and d-timely, then every f has a leader. • Server j doesn’t offer i any address only if for every f j owns, f has been reserved by another client, or the lease for fhasn’t expired. • If i is offered some f’s, then no other client is offered those f’s, so within 2d time, i gets ack for f. • Renew liveness proof similar.

21. Conclusions • Formally specified and implemented a fault tolerant DHCP algorithm using TIOA. • A simple algorithm based on decomposition into independent subproblems. • Is our decomposition “good”? • Does DHCPF need a perfect failure detector? • Is the dependence on clock skew and msg delay the best possible? • Is “goodness” merely a “human” and case-by-case concept, or a more universal one? • Perhaps nottotally far-fetched? Church-Turing formalized computation, Cook-Levin formalized completeness…

22. Thank you!