If you have a reasonably small WLAN infrastructure, you can put all your Access Points into one subnet and forget about any IP addressing issues. But even then you may still have some challenges in getting clients to roam quickly enough to support your applications (see WLAN Roaming and Make your WLAN Roam Faster).

But what happens if you are making a bigger Wi-Fi LAN, across a large campus or building? What happens if you have to go beyond one subnet?

On the wired network, you have already, of course, taken the recommended approach of a subnet per wiring closet/floor, just like they say. So now, when you put access points on each floor, you have lots of APs, all in different VLANs. And you’re supposed to make sure your users keep working as they trot up and down stairs, wander across the car park, and take their laptop to the coffee machine.

Why Keep Addresses?
If your users have reasonably new Windows laptops, DHCP will quite happily do a release and renew as the users move between APs. The PC will drop one association and make another, which will trigger an address request. By the time your user has settled down at his new position, his PC will be back on the network without him having to do anything.

That’s fine if all you need is a web browser or an email client. But any application that has short response time requirements, or can’t cope with a change in address will fail—your telnet sessions will have timed out, anything that was streaming to that particular IP address will have vanished—and you can forget any chance of a voice call surviving.

Different Vendors, Different Solutions
So a means of allowing a PC to maintain its original IP address regardless of where it’s now connected to was required. And with no standard, everyone came up with their own answer.

Mobile IP
One of the first was Mobile IP, as implemented by Cisco. Based on RFC 3220 it uses the concept of home agents (routers) and foreign agents. When a client moves from one subnet to another, but doesn’t change IP address, its new local router — the foreign agent — realises that the host is on the ‘wrong’ VLAN and basically sets up a tunnel between itself and the client’s default router — the home agent. Any traffic to or from the client can therefore continue to go via the expected default router, tunnelled to a ‘care of’ address on the new local router.

When invented, this method required Mobile IP software on clients. In a Cisco WLAN implementation, that isn't needed, since the Aironet APs support proxy Mobile IP.

There are things to be aware of here:

  • this implementation doesn’t allow multicast or broadcast traffic to be received by the roaming PC
  • It’s an IP-only implementation (not such a big issue these days)
  • you need the Cisco APs to make it work, unless you want to install Mobile IP software (such as that available from Birdstep Technology on all your client PCs.

Wireless Switches
Where Cisco’s implementation relies on a tunnel being created between home and foreign agents for every host connection that moves from one subnet to another, other companies have done things differently. For example, Trapeze Networks’ Mobility System (see our review of Trapeze's Mobility System) comprises

  • wireless switches - which Trapeze calls Mobility Exchanges (MXs)
  • access points—which Trapeze always calls Mobility Points (MPs)
  • Mobility System management software, with Ring Master software for planning and management

The MPs are completely controlled by the MXs. You can use third party APs too, but you’re going to lose a lot of the centralised management functionality (an issue that could get dealt with by the IETF's CAPWAP or other standards at some point but don't hold your breath.

So although a user’s wireless connection is with an MP, all the clever stuff is done by the MX. The MP still handles stuff like gathering RF statistics and carrying out any encryption. The MXs create tunnels between themselves over your IP network so they can talk to each other. It’s this that facilitates roaming.

Since you now have this overlay network connecting all MXs, if a user roams from one MP to another, they can still be linked back to their original subnet (MX) over this tunnel. The user keeps their original IP address, and the MXs sort out the traffic flows. Since the MX is doing all the work, there are limits as to how many MPs each can look after, depending on model.

It used to be that an MP had to be physically connected to an MX. This is no longer the case in the Trapeze topology (although it still is for some other wireless switch vendors), as an MP to MX connection can now be created (over another tunnel) across intervening switches and layer 3 boundaries. This ties in with the IETF CAPWAP effort (which stands for Control and Provisioning of Wireless Access Points) - and there’ll be more on this in a later article. The eventual CAPWAP standard looks like specifying access points and access controllers, where the latter is allowed to be directly connected to the AP, or over either a Layer 2 or Layer 3 cloud.

Wireless Routers
Another method, which is losing its differentiation thanks to the CAPWAP work, is illustrated by Chantry’s BeaconWorks, which uses BeaconPoints as APs, but its BeaconMaster is a router rather than a switch. The idea behind this was that clients would home to a router rather than be physically associated with a switch port (and therefore VLAN) and facilitate easy roaming. Since some other vendors have managed to sever the physical relationship between AP and switch, the benefits of this are les obvious.

Wireless Gateways
The other terminology you’ll see in terms of supporting Layer 3 roaming is the wireless gateway, from companies such as Bluesocket or Vernier (marketed by HP, and reviewed here). Whereas the switch/router solutions rely on APs from the same manufacturer for proper operation, the gateways don’t. Again we’re talking about tunnelling traffic across the network—the BlueSocket Wireless Gateway, for instance, creates a standard IPsec connection from the user PC across any AP, over any non-wireless-aware switches, to the gateway. Because the termination of all connections are on the gateway, rather than on multiple APs or switches, it’s easy for them to be on one subnet, since the initial IP address of the PC will be irrelevant in the IPSec setup.

Other Alternatives
If you don’t have a particularly extensive infrastructure, you could just trunk all VLANs to all areas, and present all subnets, but that’s not going to scale so it’s really a pretty short-term solution. Using IPSec, similarly to the Bluesocket setup, but terminating just on a VPN concentrator, is an option, so you can NAT all your wireless traffic and add the extra security the encryption brings you.

While these two options get round addressing changes, neither offer anything much in the way of managing your WLAN environment, and there’s not much in the way of interoperability in any of the offerings described. The CAPWAP Working Group, which will look at configuration and management, is designed to help with that, so we can hopefully expect to see continued developments in these areas.

What do you think? How important is wireless roaming between GPRS and Wi-Fi. And is it important for data or voice? Join our Forum and tell us.