Client Handoffs

Figure 3: An example handoff in the DenseAP system. The client is switched from $DAP_1$ to $DAP_2$.

The DC may sometimes want to handoff clients from one DAP to another, for load balancing or because the client's location has changed. Figure 3 illustrates the sequence of steps that lead to a seamless handoff in DenseAP.

Assume that client $C$ has successfully associated with $DAP_1$. The following steps are taken when the DC decides to handoff $C$ from $DAP_1$ to $DAP_2$. (i) The DC adds $C_{mac}$ to the ACL on $DAP_2$. (ii) To ensure any further traffic flowing towards $C$ is routed via $DAP_2$, $DAP_2$ sends out a gratuitous proxy ARP message containing $C_{IP}$ and $DAP_2^{mac}$ to the wired subnet. (iii) The DC asks $DAP_1$ to send a disassociate frame to $C$. (iv) $DAP_1$ removes $C^{mac}$ from the local ACL and sends a disassociate frame to $C$. It also cleans up all local association state pertaining to $C$. (v) $C$ receives the disassociate frame and immediately begins to scan for other DAPs by sending out probe requests. (vi) Upon receiving $C$'s probe request, $DAP_2$ responds with a probe response.

After associating with $DAP_2$, $C$ does not send out a DHCP request since the time taken to re-associate did not cause a local media-disconnect event. Therefore, it is important to ensure that the DC only hands off clients between DAPs that are on the same subnet. In practice, we expect that all DAPs managed by a DC will be on the same wired subnet. We present results illustrating the efficacy of our handoff mechanism in Section 6, along with time required for each step.

Having described the mechanisms by for enforcing the association decisions, we now describe the policy for making these decisions.