WiFi WLAN Roaming Basics

Wireless LANs whole point is is the convenience of the mobility you get being able to wander from one part of the office to the other. Users expect the same completely transparent service they get as their mobile phones move from one cell to another, but in the world of 802.11 it’s not actually that easy. There’s a lot of publicity about roaming in Wi-Fi just now, for instance a new IEEE group on testing Wi-Fi has found that it is impossible to compare roaming times without a definition of roaming. While many wireless switch vendors make a point of roaming at Layer 3 (a technology we’ll cover the technicalities of in a later article), several other vendors (such as Bluesocket and Vernier, reviewed here under its HP badge) solve the problem by keeping all access points on a single subnet, so the roaming only happens at Layer 2 and the roaming device keeps the same IP address. What most people miss is that even roaming within a subnet, at Layer 2, has its challenges. What’s involved?

When a WLAN client moves from the range of one Access Point (AP) to another in the same subnet, it needs to find the best AP, decide when to roam onto it, associate with it and do any authentication required, as per your security policies. Then the wired network has to relearn the location of the client, so that data can be sent to it. All of this takes time and this is without the client having to worry about getting a new IP address! The scanning and decision making part of the roaming process (see How to Make your WLAN roam faster) allows the client to find a new AP on an appropriate channel as the user moves. When this happens, the client must associate with the new AP. It must then, assuming that it is an 802.1x supplicant (see The EAP Heap), reauthenticate with the RADIUS server. This is transparent to the user - but the delay in this happening may not be. It can take up to a second for association and authentication to occur (see below for implications and solutions). IAPP
The next part of the process is for the rest of the network to be made aware that the client has shifted. This calls for AP to AP communication, which was never catered for in the original 802.11 spec. Vendors had their own way of passing updates; however 802.11f, the Inter-Access Point Protocol, has now been now published by the IEEE as a trial-use standard - it sits in this state for two years before being submitted as a full-use standard - to facilitate multi-vendor AP interoperability. IAPP calls for the new servicing AP to send out two packets onto the wired LAN. One of these is actually set with the source address of the client (the standard says this should be a broadcast, however some implementations still use unicast to the previous AP or a multicast) and is used by intervening switches to update their MAC address tables with the client’s new location. The other is an IAPP ADD-notify packet from the new AP to an IAPP multicast address that all APs subscribe to, which contains the MAC address of the station it has just associated. All APs will receive this packet, and the one that had been associated with that station will use the sequence number included to determine that this is newer information and remove the stale association from its internal table. IAPP provides for the sharing of information between APs. The format of this information is specified, as "contexts" but the actual content is not defined, so it’s not yet hugely useful as far as vendor interoperability is concerned. Also IAPP has no specific provision for security. Who Cares?
So, worst case, you’re probably looking at about one second where your client can’t be reached over the network. For a lot of clients and applications, this isn’t an issue. If you’re walking from one room to another carrying your laptop, and you want to use email or a web browser, it’s not a problem. In fact, most TCP-based applications will be able to handle this sort of hiccup (remember that in this instance there’s no address change). UDP applications are less able to handle interruptions, and unfortunately, these are the ones where a break would be most noticed by the user. The killer? Voice. Not only is VoWLAN UDP-based for the bearer traffic, but it’s also the one application where you are likely to be using it as you move between APs. And you are definitely going to notice a one second hit. Which is presumably why the vendors that are pushing fast roaming for 802.11 are the ones squarely behind the use of wireless handsets in an IP Telephony environment, such as Cisco, SpectraLink and Symbol. Related standards
In fact these are three of the companies behind the drive for a new IEEE Working Group to create a standard to handle faster Layer 2 roaming. There are several related standards and works-in-progress, but none that actually cover this specific aspect:

* As already discussed, IAPP—802.11f—isn’t designed for speed.
* 802.11i, the security standard (not yet ratified) has provision for secure fast handoff, but it’s too security specific for this requirement.
* 802.11k—Radio Resource Management—might help in that it should cater for faster discovery of APs. Again, not yet finalised.
* 802.21 isn’t specifically for wireless LANs at all. It’s aimed at the handoff between heterogeneous networks (wired, 802.11, Bluetooth) and while it will deal with inter-ESS roaming (ie subnet to subnet in a WLAN), it won’t speed up the Layer 2 process which is needed prior to any Layer 3 interaction. This was the P802 Handoff Study Group, and is just in the process of kicking off now.

Fast roaming now
In the meantime of course, there are proprietary solutions. The two parts that need to be speeded up to cut down outage times are the scanning process (to allow clients to find new suitable APs to associate to), and, specifically for security, a faster way of reauthenicating to cut out the RADIUS request/response process. There are things that can be done to speed up the time it takes for a client to find another suitable AP. An AP can maintain information on its adjacent APs, which it can pass to a client on request—this will give the client a better indication of usable channels to scan, for example. The biggest time saver, however, is reckoned to be in localising the 802.1x authentication process. Cisco has incorporated Fast Secure Roaming into its Wireless Domain Services (WDS) portfolio as part of its Structured Wireless Aware Networking offering, which in effect allows an AP on each local subnet to act as the authenticator for clients. When a client (or other AP) goes through the initial RADIUS authentication, it does it via one AP running WDS. This lets that AP establish shared keys between itself and every other entity in the L2 domain, and allows for quicker reauthentication. Plans are for this capability to be included in Cisco’s router/switch platforms later this year as part of its SWAN development. Symbol provides similar functionality in its hardware, while Airespace) also caters for fast roaming in its wireless switches and appliances, and companies such as Bluesocket, which use gateways to control pretty dumb APs, manage everything centrally. Proxim handles things differently, pre-authenticating clients to nearby APs as well as the one currently in use in preparation for the client moving. So before you get excited about Layer 3 roaming, make sure you understand how your vendor of choice implements it at Layer 2. If that bit’s not fast enough to stop you losing traffic, you’ll never be able to move across subnets. It’s likely to be years before there’s a usable standard in place and in the meantime while you can probably get APs from different vendors to work together, there’s no guarantee of interoperability if you want to turn on their various fast roaming options.