9.2 Fast Roaming Protocols & Mobility Architecture (802.11r, 802.11k, 802.11v, 802.11w)

9.2 Fast Roaming Protocols & Mobility Architecture (802.11r, 802.11k, 802.11v, 802.11w)

Core Blueprint Focus: Seamless client roaming across high-density enterprise access points without voice degradation or packet drops is a core objective of Domain 5.0 (Client Connectivity Configuration). Understanding the fundamental distinctions between Layer 2 and Layer 3 roaming, inter-controller mobility, and the cryptographic mechanics of IEEE 802.11r Fast BSS Transition (FT) is heavily tested on the Cisco WLCOR 350-101 exam. Candidates must master the 802.11r key hierarchy (MSK, PMK-R0, PMK-R1, PTK), compare Over-the-Air versus Over-the-DS transition frames, and evaluate how 802.11k Neighbor Reports and 802.11v BSS Transition Management resolve the sticky client dilemma.

---

1. Roaming Fundamentals: Intra- vs. Inter-Controller & Layer 2 vs. Layer 3

When an 802.11 station moves through an enterprise facility, physical attenuation and RF multipath degrade its connection to the current Access Point. The client must re-establish its Layer 2 radio association with a neighboring AP broadcasting the identical Extended Service Set Identifier (ESSID). How the wireless and wired infrastructure handles this handoff depends on controller distribution and IP subnet boundaries.

+-----------------------------------------------------------------------------------------+
|                               ROAMING TAXONOMY MATRIX                                   |
|                                                                                         |
|  +-----------------------------------------------------------------------------------+  |
|  |                                  INTRA-CONTROLLER                                 |  |
|  |  - Serving AP and Target AP terminate on the SAME Catalyst 9800 WLC               |  |
|  |  - Always Layer 2 (Client retains IP; WLC simply remaps client CAPWAP binding)    |  |
|  +-----------------------------------------------------------------------------------+  |
|                                            |                                            |
|                                            v                                            |
|  +-----------------------------------------------------------------------------------+  |
|  |                                  INTER-CONTROLLER                                 |  |
|  |  - Serving AP and Target AP terminate on DIFFERENT Catalyst 9800 WLCs             |  |
|  |                                                                                   |  |
|  |  +-----------------------------------------+ +----------------------------------+ |  |
|  |  |           LAYER 2 ROAMING               | |         LAYER 3 ROAMING          | |  |
|  |  | - Both WLCs share the identical client  | | - Target AP is on a DIFFERENT    | |  |
|  |  |   VLAN and IP subnet                    | |   VLAN and IP subnet             | |  |
|  |  | - Client keeps IP address natively      | | - Requires Foreign-Anchor Tunnel | |  |
|  |  | - Switches update CAM tables via GARP   | |   (CAPWAP UDP 16666/16667)       | |  |
|  |  +-----------------------------------------+ +----------------------------------+ |  |
|  +-----------------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------------+

Intra-Controller Roaming

In an intra-controller roam, both the original serving AP and the target AP terminate their CAPWAP tunnels on the same physical or virtual Catalyst 9800 WLC. When the client transmits an 802.11 Reassociation Request to the target AP, the target AP forwards the frame to the WLC. The controller:

1. Updates its internal client database, updating the client's association binding from AP-1 to AP-2.
2. Redirects the downstream CAPWAP data tunnel forwarding path from AP-1 to AP-2.
3. Maintains the client's existing security context, IP address binding, and Quality of Service (QoS) state without needing external mobility signaling.

Inter-Controller Layer 2 Roaming

In an inter-controller Layer 2 roam, the serving AP resides on WLC-1 and the target AP resides on WLC-2, but both controllers share the identical client VLAN and IP subnet (e.g., VLAN 10, 10.10.10.0/24):

1. WLC-1 and WLC-2 exchange mobility control messages across their mobility group peer relationship.
2. WLC-1 transfers the client's state database (including MAC address, PMK security context, and QoS profile) to WLC-2.
3. WLC-2 assumes ownership of the client and transmits a Gratuitous ARP (GARP) or Reverse ARP (RARP) frame into the wired access switch network.
4. Upstream campus switches update their Content Addressable Memory (CAM) tables, redirecting frames destined for the client's MAC address to the switchport connected to WLC-2. The client retains its original IP address without renewing its DHCP lease.

Inter-Controller Layer 3 Roaming

In large campus environments spanning multiple buildings or distribution blocks, APs are frequently mapped to different Layer 3 routed subnets (e.g., Building A uses VLAN 10, 10.10.10.0/24; Building B uses VLAN 20, 10.10.20.0/24).

If a client roaming from Building A to Building B were forced to release its IP and request a new DHCP lease on VLAN 20, all active Layer 4 TCP connections, real-time UDP streams (VoIP/video calls), and secure VPN tunnels would abruptly disconnect. To eliminate session disruption, Cisco mobility implements Layer 3 Roaming (Foreign-Anchor Tunneling):

• Anchor WLC: The original controller (WLC-1) where the client first authenticated and obtained its IP address (10.10.10.55).
• Foreign WLC: The new controller (WLC-2) where the client roamed.
• Mobility Tunnel: WLC-2 establishes an inter-controller CAPWAP mobility data tunnel back to WLC-1. When the client transmits data, WLC-2 encapsulates the packets inside CAPWAP data (UDP 16667) and routes them across the campus core to WLC-1. WLC-1 decapsulates the packets and injects them onto the original VLAN 10 gateway. Return traffic from the core routes to WLC-1, which tunnels it back to WLC-2 for delivery to the client. The client retains its original IP address and default gateway indefinitely.

---

2. IEEE 802.11r Fast BSS Transition (FT)

In standard 802.1X enterprise networks, roaming incurs substantial latency that severely degrades real-time voice and video applications. Understanding the cryptographic foundation of IEEE 802.11r Fast BSS Transition (FT) is critical for the WLCOR exam.

The Roaming Latency Problem

Under standard 802.11 / 802.1X operation without fast roaming, when a client roams from AP-1 to AP-2, it must execute:

1. 802.11 Open Authentication (2 frames).
2. 802.11 Reassociation (2 frames).
3. Full 802.1X/EAP Exchange: EAP-Identity, EAP-TLS or PEAP handshakes with Cisco ISE across the wired network (requiring 8 to 16 round-trip packets).
4. 4-Way Handshake: EAPOL-Key exchanges between client and AP-2 to derive the Pairwise Transient Key (PTK).

This entire full re-authentication sequence consumes 200 ms to 500 ms (or longer if RADIUS servers traverse WAN links). Real-time voice-over-Wi-Fi (VoWLAN) requires handoff latency under 50 ms; latencies above 50 ms produce audible jitter, voice clipping, or dropped calls.

The 802.11r Key Hierarchy

IEEE 802.11r eliminates the 802.1X re-authentication and 4-way handshake during roams by introducing a two-tier cryptographic key distribution hierarchy:

+-----------------------------------------------------------------------------------------+
|                                 802.11r KEY HIERARCHY                                   |
|                                                                                         |
|               [ Initial 802.1X / EAP Authentication with Cisco ISE ]                    |
|                                          |                                              |
|                                          v                                              |
|                             Master Session Key (MSK)                                    |
|                            (512-bit Secret from RADIUS)                                 |
|                                          |                                              |
|                                          v                                              |
|                         Pairwise Master Key R0 (PMK-R0)                                 |
|                    - Held by Key Holder R0 (R0KH): Catalyst 9800 WLC                    |
|                    - Derived from MSK, SSID, MDID, R0KH-ID, S0KH-ID                     |
|                                          |                                              |
|                   +----------------------+----------------------+                       |
|                   |                                             |                       |
|                   v                                             v                       |
|      Pairwise Master Key R1 (PMK-R1)               Pairwise Master Key R1 (PMK-R1)      |
|   - Pushed to Target AP-1 (R1KH)                - Pushed to Target AP-2 (R1KH)          |
|   - Derived from PMK-R0, BSSID-1, S1KH-ID       - Derived from PMK-R0, BSSID-2, S1KH-ID |
|                   |                                             |                       |
|                   v                                             v                       |
|      Pairwise Transient Key (PTK)                  Pairwise Transient Key (PTK)         |
|   - Encrypts Data between STA & AP-1            - Encrypts Data between STA & AP-2      |
|   - Derived during Fast 2-Frame Exchange        - Derived during Fast 2-Frame Exchange  |
+-----------------------------------------------------------------------------------------+

1. Master Session Key (MSK): Derived during the initial full 802.1X authentication between the client and Cisco ISE.
2. Pairwise Master Key R0 (PMK-R0): The first-tier key derived from the MSK, the Mobility Domain ID (MDID), the client MAC, and the WLC's identifier. The WLC acts as the R0 Key Holder (R0KH).
3. Pairwise Master Key R1 (PMK-R1): The second-tier key derived from the PMK-R0 and the target AP's BSSID. The WLC (R0KH) calculates the PMK-R1 specifically for each target AP and pushes it down across CAPWAP to the target AP, which acts as the R1 Key Holder (R1KH). The client independently calculates the identical PMK-R1.
4. Pairwise Transient Key (PTK): The operational encryption key (AES-CCMP) derived using PMK-R1, SNonce, and ANonce directly during the Fast Transition reassociation frames over the air.

Over-the-Air vs. Over-the-DS Transition Methods

IEEE 802.11r defines two operational transport methods for executing a fast BSS transition:

+-----------------------------------------------------------------------------------------+
|                        802.11r TRANSITION OPERATIONAL METHODS                           |
|                                                                                         |
|  METHOD 1: OVER-THE-AIR                                                                 |
|  ---------------------                                                                 |
|  1. Client changes radio channel to Target AP channel.                                  |
|  2. [Client] ---- FT Authentication Request (SNonce) -----------> [Target AP]           |
|  3. [Client] <--- FT Authentication Response (ANonce) ---------- [Target AP]           |
|  4. [Client] ---- FT Reassociation Request ---------------------> [Target AP]           |
|  5. [Client] <--- FT Reassociation Response (FTE, GTK) ---------- [Target AP]           |
|                                                                                         |
|  METHOD 2: OVER-THE-DISTRIBUTION SYSTEM (OVER-THE-DS)                                   |
|  ----------------------------------------------------                                   |
|  1. Client REMAINS on Current AP channel (Zero audio interruption).                     |
|  2. [Client] ---- FT Action Request (via Current AP) -----------> [Target AP over DS]  |
|  3. [Client] <--- FT Action Response (via Current AP) ---------- [Target AP over DS]  |
|  4. Client tunes radio to Target AP channel.                                            |
|  5. [Client] ---- FT Reassociation Request ---------------------> [Target AP]           |
|  6. [Client] <--- FT Reassociation Response (FTE, GTK) ---------- [Target AP]           |
+-----------------------------------------------------------------------------------------+

• Over-the-Air FT: The client tunes to the target AP’s channel, exchanges FT authentication frames directly over RF, and completes reassociation. Frame count, scanning, timing, and support depend on the client and deployment; tuning away from the serving channel can introduce a brief traffic pause.
• Over-the-DS FT: The client remains associated to its current AP and operating on its current channel. It encapsulates its FT Action Request inside an 802.11 Action frame transmitted to the current AP. The current AP forwards the request across the wired Distribution System (DS) or WLC to the target AP. The target AP returns its FT Action Response across the DS. Only after mutual authentication is complete does the client switch channels to transmit the final FT Reassociation Request. This avoids retuning for the FT authentication exchange itself; it does not eliminate the client’s separate need to discover and evaluate candidate channels.

Adaptive 802.11r (Cisco & Apple)

Under standard 802.11r, the WLAN must advertise specialized Authentication and Key Management (AKM) suites (AKM 3 for FT-802.1X or AKM 4 for FT-PSK). Legacy clients that do not support 802.11r cannot parse these AKMs and refuse to associate, historically forcing enterprises to deploy dual SSIDs (Corp and Corp-FT).

To solve this, Cisco and Apple engineered Adaptive 802.11r:

• The Catalyst 9800 advertises standard WPA2/WPA3 AKM suites in the public 802.11 Beacon frames, allowing legacy non-FT clients to connect normally.
• A proprietary Cisco vendor-specific Information Element (IE) is included, signaling 802.11r support to iOS/macOS and compatible devices.
• Compliant devices recognize the capability and dynamically negotiate 802.11r Fast BSS Transition on the single corporate SSID.

---

3. Legacy Fast Roaming: PMK Caching & Opportunistic Key Caching (OKC)

Prior to the ratification and widespread adoption of 802.11r, the wireless industry developed two intermediate fast roaming technologies:

Standard IEEE 802.11i PMK Caching

Under baseline 802.11i, when a client completes a full 802.1X authentication with AP-1, both the client and AP-1 cache the resulting Pairwise Master Key (PMK) along with an identifier called the PMKID: $\text{PMKID} = \text{HMAC-SHA1}(\text{PMK}, \text{"PMK Name"} \parallel \text{Client MAC} \parallel \text{AP BSSID})$

• If the client roams to AP-2, it must undergo a full 802.1X re-authentication.
• However, if the client later roams back to AP-1, it includes the cached PMKID in its 802.11 Reassociation Request frame.
• If AP-1 still maintains the matching PMKID in its cache, full 802.1X is bypassed. The client and AP-1 proceed directly to the 4-Way Handshake, reducing roam time from ~400 ms to ~100 ms.
• Limitation: PMK caching only accelerates roams back to APs the client has previously visited. The initial roam to any newly encountered AP requires full 802.1X re-authentication.

Opportunistic Key Caching (OKC)

Developed collaboratively by Cisco and Microsoft, Opportunistic Key Caching (OKC) (also known as Proactive Key Caching [PKC]) overcomes the limitation of baseline PMK caching:

• When a client completes initial 802.1X authentication with AP-1, the central Catalyst 9800 WLC caches the master PMK.
• The WLC proactively distributes the client's PMK across all other APs joined to the controller.
• When the client roams to AP-2 (an AP it has never visited before), the client calculates the expected PMKID for AP-2 and inserts it into its Reassociation Request.
• Because WLC pre-populated AP-2 with the shared PMK, AP-2 recognizes the PMKID, skips full 802.1X authentication, and executes only the 4-Way Handshake (~100 ms roam latency).
• Limitation: OKC is not a formally ratified IEEE standard. Furthermore, OKC does not operate across controllers without synchronized mobility key sharing, whereas 802.11r natively scales across the entire mobility domain.

---

4. Assisted Roaming Protocols: 802.11k & 802.11v

Fast roaming protocols (802.11r, OKC) solve the authentication latency problem, but they do not solve the discovery latency problem (channel scanning) or the sticky client problem. IEEE 802.11k and 802.11v provide network-assisted roaming intelligence.

+-----------------------------------------------------------------------------------------+
|                       ASSISTED ROAMING PROTOCOL COOPERATION                             |
|                                                                                         |
|  +-----------------------------------------------------------------------------------+  |
|  |                     IEEE 802.11k (Radio Resource Measurement)                     |  |
|  |  * Problem Solved: DISCOVERY SCANNING LATENCY                                     |  |
|  |  * Mechanism: Client queries serving AP for Neighbor Report                       |  |
|  |  * Result: AP returns targeted list of neighboring BSSIDs, channels, and PHY types|  |
|  |  * Latency Reduction: Scanning shrinks from 500 ms (all channels) to < 20 ms      |  |
|  +-----------------------------------------------------------------------------------+  |
|                                            |                                            |
|                                            v                                            |
|  +-----------------------------------------------------------------------------------+  |
|  |                  IEEE 802.11v (BSS Transition Management - BTM)                   |  |
|  |  * Problem Solved: STICKY CLIENT SYNDROME                                         |  |
|  |  * Mechanism: WLC/AP detects weak client signal (-80 dBm) or cell congestion      |  |
|  |  * Action: AP sends BTM Request advising client to steer to a superior AP         |  |
|  |  * Enforcement: Optional "Disassociation Imminent" timer forces stubborn clients  |  |
|  +-----------------------------------------------------------------------------------+  |
|                                            |                                            |
|                                            v                                            |
|  +-----------------------------------------------------------------------------------+  |
|  |                   IEEE 802.11r (Fast BSS Transition - FT)                         |  |
|  |  * Problem Solved: 802.1X AUTHENTICATION LATENCY                                  |  |
|  |  * Mechanism: Pre-derived PMK-R1 keys execute sub-50 ms handoff                  |  |
|  +-----------------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------------+

IEEE 802.11k: Radio Resource Measurement (RRM) & Neighbor Reports

When a client's signal degrades, it must locate a candidate AP. Scanning all 2.4 GHz, 5 GHz, and 6 GHz channels (spanning up to 80+ regulatory channels) consumes 300 ms to 500 ms of off-channel radio time, dropping packets.

IEEE 802.11k resolves this via Neighbor Reports:

1. The client transmits an 802.11k Neighbor Report Request (Action frame) to its current AP.
2. The serving AP consults the Catalyst 9800 Radio Resource Management (RRM) database and responds with an 802.11k Neighbor Report Response.
3. The report contains a prioritized list of candidate APs: BSSIDs, operating channel numbers, PHY types (802.11ax/6E), regulatory domains, and BSSID information elements indicating whether the neighbor supports 802.11r.
4. The client skips full-spectrum scanning and transmits targeted unicast probes only on the specific channels where neighbor APs reside, pruning discovery time down to < 20 ms.

IEEE 802.11v: BSS Transition Management (BTM)

A major operational challenge in enterprise WLANs is the "sticky client"—a mobile device that associates to an AP at the entrance of a building and clings to that AP at -82 dBm even after walking deep into the facility beneath APs broadcasting at -52 dBm. Sticky clients consume excessive airtime transmitting at the lowest Modulation and Coding Scheme (MCS) data rates, degrading the entire RF cell.

IEEE 802.11v BSS Transition Management (BTM) provides network-directed client steering:

1. The Catalyst 9800 WLC and AP monitor client metrics (RSSI, SNR, packet error rate, and AP channel utilization).
2. When client RSSI drops below a configured threshold (e.g., -72 dBm) or the serving AP experiences high channel load, the AP transmits an 802.11v BTM Request frame to the client.
3. The BTM Request includes a candidate list of superior neighbor BSSIDs, their current channel utilization, and preference weights.
4. The client evaluates the list and returns an 802.11v BTM Response frame indicating whether it accepts or rejects the transition.
5. Disassociation Imminent: If a sticky client repeatedly ignores advisory BTM requests, the AP can send a BTM Request with the Disassociation Imminent bit set to 1 and a countdown timer (e.g., 200 ms). If the client fails to roam before the timer expires, the AP forcibly disassociates the client, compelling it to reassociate to the optimal neighboring AP.

Fast Roaming Technologies Comparison Matrix

---

5. Catalyst 9800 Configuration and CLI Diagnostics

Configuring fast transition and assisted roaming on Cisco Catalyst 9800 Series Wireless LAN Controllers is managed within the WLAN Profile settings:

! Enter WLAN Configuration Mode
C9800-01(config)# wlan Enterprise-WLAN 1 Enterprise-Secure

! Enable 802.11r Fast Transition (FT)
C9800-01(config-wlan)# security ft
C9800-01(config-wlan)# security ft over-the-ds
! Optional: Enable Adaptive FT for seamless non-FT/FT coexistence
C9800-01(config-wlan)# security ft adaptive

! Enable 802.11k Radio Resource Measurement Neighbor Reports
C9800-01(config-wlan)# assisted-roaming neighbor-list
C9800-01(config-wlan)# assisted-roaming dual-list

! Enable 802.11v BSS Transition Management (BTM)
C9800-01(config-wlan)# bss-transition

! Enable 802.11w Protected Management Frames (PMF)
C9800-01(config-wlan)# security pmf optional
exit

! Operational Verification Commands
C9800-01# show wireless client mac-address a483.e722.9104 detail
! Verify 802.11r FT Negotiation, AKM Suite, and PMF Status

C9800-01# show wireless client mac-address a483.e722.9104 mobility
! Displays client mobility state, Foreign/Anchor roles, and roam history