802.11r

802.11r purpose

802.11r (AKA Fast Transition) is an IEEE 802.11 amendment published in 2008. The problem they were trying to solve at that time was as follows: when you roam from one cell to the other, you waste time. This is because your device stays associated to the current cell until the signal becomes too poor to be usable and then (only then):

• Leaves the channel to scan and discover other channels where the SSID is available (this scanning process wastes times, in a configuration where your communication is already bad)
• Once a new AP is chosen, the device needs to authenticate to that new AP, the disassociate from the old AP, then associate to the new AP. 

In a voice call, where every millisecond counts, this can take too long (you need to re-enter a 4 way WPA2 handshake, and maybe even get back to the RADIUS, before have a key that you can use). This process can be disruptive. The other bad news is that you have no idea on whether the new AP can continue your call or not (it may be completely overloaded already).

So 802.11r was designed to allow your device to run the next AP discovery process before leaving the previous cell, including negotiating the key with the new AP, and checking that the new AP can provide the same QoS services as the older one... and only then, once everything is ready, the device would make the short jump to the next AP. 802.11r can save a lot of time. In the illustration below, I roamed back and forth between two APs (WPA2/PSK). In the first case, 802.11r is not enabled.

Each blue diamond is the time elapsed between the last voice packet in the previous cell, and the first voice packet in the next cell. Depending on the scanning structure of the phone, you can see that I sometimes get to the next AP in a few tens of milliseconds, but sometimes performances are poor.
In the second example below, I enabled 802.11r on my APs, and performances are much better (careful, scale above is in seconds, because I get some long intervals, while the scale below is in MILLIseconds)..

802.11r process

802.11r is an extension to 802.11i. In other words, you can enable 802.11r only for your WPA2/CCKM WLANs (not WPAv1, not WPA2/TKIP, not for Open or WEP). At that time, the AP displays in its beacons and the Probe responses the FT information in 2 fields:

• The Mobility domain contains a hash value that is shared by all APs in the same 802.11r domain (i.e. between which 802.11r fast roaming is possible). In Cisco autonomous APs, this hash is derived from the IP address of your WDS. In a controller system, It is derived from the mobility group value.
• The Mobility domain section also mentions if QoS reservation (resource request protocol) is supported. Very few systems implement RRP, because it removes the intelligence from the client. It is usually better and more efficient to let the client assess the next cell load through QBSS IE information and decide of the best course of action, rather than constraining the client to negotiate QoS parameters.
• The Mobility domain section also mentions if negotiation with the next AP has to happen over the air, or over the DS (more on this below).   
• The RSN (Robust Security Network) field displays that Key management includes FT (with PSK or 802.1x, depending on how your clients authenticate).

Note: on Cisco controllers, (8.0 and later), you can enable "hybrid" WLANs, where you turn on either FT, WPA2/CCKM, or both. In this last case, you would see both FT and PSK (or 802.1x) key management:

Over the DS vs Over the Air:
Negotiation with the next AP can happen over the air, or over the DS. With "over the air", the client gets to the edge of the first cell, scans, finds another AP, and negotiates directly with this next AP the next key (and possibly QoS parameters). The advantage of this method is that communication is direct (no delay by going through the DS, not need for AP to AP wired communication protocol). The downside is that the client needs to leave its active channel to negotiate on another channel. Most BYODs send a frame to their current AP, telling them that they "go to sleep" (Null frame with Power Management set to 1, while in fact they go negotiate on another channel), then return to the active channel to "empty their and the AP buffer" (Null frame with Power management set to 0) before jumping out to the next AP.
The over the air process is direct, but may be disrupting in a location where the device is already at the edge of the cell (low data rate, lots of retries). To avoid that the negotiation also forces the device to go off channel for a while, the Over the DS method can be enabled. In this case, the device stays on the current channel (no need to pretend to sleep and leave the channel), and asks the current AP to negotiate with the next AP (your client still has to discover the next AP first, i.e. scan). This process saves time and increases efficiency, provided that both APs have a way to communicate. In a controller-based network, no problem. The unknown is in the efficiency (what is faster: direct negotiation, or going through the current AP, the WLC, then the next AP, with all the switches or routers that may be on the way?). The only answer is to test (or know your network, if APs are on the same switch and the WLC is close, DS is great. Add routers and switches, and the needle switches toward Over the air).

Key negotiation:
The major difference between 802.11r and standard WPA2/CCMP lies in the key negotiation. With standard WPA2/CCMP, the client and the RADIUS server generate a Master Session Key (MSK), which first 256 bits are used as the Pairwise Master Key, from which individual encryption keys (TK, temporal keys) are derived for individual frame encryption. With PSK (no RADIUS), the PSK is the MSK. The PMK is valid for the duration of the session, and roaming usually means renegotiating a new PMK (I am ignoring PMK caching various forms).
With 802.11r, the PMK derived from the MSK is in fact called PMK-R0. That key is kept where the authentication occurred (WLC, or first AP in an autonomous network). A second PMK is generated from the PMK-0; it is called PMK-R1. That PMK is the one used to derive the TK on the first AP. When the client negotiates with the next AP, the "domain ID" field and a PMK-R0 identifier tell if the next AP is in the same 802.11r domain as the previous AP, i.e. if the next AP also has access to the same PMK-R0. If domain is the same, then the client agrees with the next AP to generate a new PMK-R1 (from the same PMK-R0 in the central repository). The next PMK-R1 is passed to the next AP, and everything is ready.
In other words, client and next AP just need to know that they are in the same domain, and agree on the next PMK-R1 index. Then the client generates the new PMK-R1 on its side, while the next AP gets the same PMK-R1 from the wired side (WLC or WDS). No need for the client to perform authentication again.
During the 4 way handshake (FT style), the PMK-R0 and R1s are mentioned as part of the exchange (frame 2 of the 4 way handshake, sent from the AP, below):

The domain and PMK-R0 identifiers are enough to ensure that the device is in the same domain from one AP to the next, and the rest negotiates the PMK-R1 details.

The downside of this method is that non-802.11r client do not understand the "FT" key management method in the beacons and probe responses, and also do not understand the domain and key index in the 4 way handshakes. In short, they can't associate to WLANs set for 802.11r. This is the reason for the "hybrid" mode, where you configure both WPA2 and FT. non-802.11r associate using WPA2, while clients that support 802.11r use the more efficient FT method.
There are still some old clients that panic when seeing "FT" mentioned in the beacons/probe responses, even if WPA2 is there. This is because (poor programming) they do not recognize this security parameter, and refuse to associate, even if they do recognize WPA2. These older and poorly developed drivers tend to go away with newer devices and OS updates, but make sure to test 802.11r in your network before deploying it completely.

802.11r Configuration:

This is the easy part. In your WLAN, start by setting security to WPA+WPA2, then check Fast Transition (FT).  Default negotiation is over the Air, check Over the DS otherwise.
Clients can negotiate keys with the next AP, and then never jump there. The reassociation timeout determines the duration for which the newly negotiated key is valid. By default, if the client does not make the jump within 20 seconds, the next AP cancels the PMK-R1, considering that the client went elsewhere.

At the bottom of the screen, check FT 802.1X or FT PSK to enable 802.1X or PSK for 802.11r clients, and optionally also check 802.1X or PSK for the WPA2 clients (thus making the WLAN 'hybrid').
Of course, mode has to be the same for both (802.1X and FT 802.1X, OR PSK and FT PSK).

Click Apply. Done.
Use show wlan wlan-id and show client detailed to check your config. You cannot change the domain ID without changing WLC mobility configuration. Use debug ft keys {enable | disable} to follow the FT dialog from the WLC CLI.