Wireless networking and mobility are intertwined concepts. Without mobility, wireless networking would not be particularly interesting. Mobility means that applications just work, no matter where the computer is. Unfortunately, building a network that provides location-independent services requires a great deal of location-based configuration and knowledge.

Translating the high-level definition of mobility into technical details can be done in several different ways. Many technologies can be used to provide mobility for network users, and not all of them are good. Providing network transport that is truly independent of the application and transparent to it has several requirements.

No single technology supplies all of the components of mobility. At the link layer, much is provided by 802.11, although additional functionality is often required above and beyond what the standard lays out. By and large, moving the association between access points is easy. In networks that do not use link-layer security, bridging records can be transferred between access points in a few milliseconds to tens of milliseconds. Re-establishing the link-layer security context may take a few hundred milliseconds, and depends heavily on the responsiveness of the authentication server. Some companies have devoted significant engineering resources to building products that accelerate the security context establishment. Newer “Wi-Fi switch” products may also speed up the roaming process by holding client association records in a centralized location so that there is no need to transfer it between APs.

At the network layer, several different approaches may be taken to offer network-layer mobility. Several early devices used address translation (NAT). NAT is not, never has been, and never will be a mobility protocol. By dragging the network infrastructure up into higher protocol layers, any failure of the translation breaks applications. Some applications are almost incompatible with NAT, such as H.323, while others require specific application support, such as IPsec’s use of NAT Traversal. Some devices rely heavily on NAT to provide mobility. Avoid them.

Some form of tunneling is often used to provide application-independent mobility. Client devices are designated with a “home” network, and then inter-AP protocols automatically direct traffic back to the home location from any place it is not directly accessible. Tunneling protocols must be defined at the network layer so that tunnels can carry data across arbitrary network boundaries. However, the tunneling protocol itself may work at the link layer (making VLAN attachment points available throughout the network) or at the network layer (making IP addresses routable throughout the network). The only open industry standard tunneling protocol is Mobile IP (see sidebar later in this chapter).

One challenge network architects often face is the distance over which mobility must be provided. Small installations are easy because there are a number of techniques that offer comparable functionality for up to 25 access points. The real challenges come when designing mobility for larger installations, or organizations that have widely distributed locations. Part of the key to designing a successful mobility solution is to determine what users expect. What sort of tasks require that an IP address be continuously maintained? Interactive terminal sessions, such as telnet and SSH, require that the source IP address remain the same. Other applications may be able to initiate new connections upon reattaching to the network, and the process of reconnecting may be transparent to the users. Generally speaking, most users do not expect to maintain an IP address if they need to use a car, train, or plane to travel between network sites. Still, large, spread-out campuses might require higher-than-average mobility support.

I have omitted a great deal of the protocol operations. Designing a protocol to allow a station to attach anywhere in the world and use an address from its home network is a significant engineering endeavor. Several security problems are evident, most notably the authentication of protocol operations and the security of the redirected packets from the home network to the mobile station’s current location. Maintaining accurate routing information, both the traditional forwarding tables at Internet gateways and the Mobile IP agents, is a major challenge. And, of course, the protocol must work with both IPv4 and IPv6. For a far more detailed treatment of Mobile IP, I highly recommend Mobile IP: Design Principles and Practices by Charles Perkins (Prentice Hall).

Extending existing VLANs over the air is one of the major tasks that standards groups are working on. In the meantime, vendors have taken a variety of approaches. As you evaluate these approaches, there are a few fundamentals.

802.11 built in the concept of having multiple “service sets,” but did not explicitly define what a service set was. Moreover, there are two types of service set identifiers (SSIDs) in 802.11. Extended Service Set IDs (ESSIDs) are “network names.”^[90] Multiple APs can be configured to advertise a set of connections into the air. When a client wishes to connect to a wireless network, it issues probes for the ESSID it is trying to find, and APs belonging to that SSID respond. ESSIDs can be transmitted in Beacon frames, although they do not have to be. (ESSID hiding is a security-through-obscurity practice; if you flip back to Chapter 9 you will note that the Probe Response frame includes the unencrypted SSID.) The second type of service set, the Basic Service Set ID (BSSID), is the MAC address of the AP. It is used as the transmitter or receiver address on frames that are bridged between the wireless and wired networks.

Generally speaking, each ESSID being transmitted should have its own BSSID. Although there is nothing to prevent an access point from transmitting multiple ESSIDs in a single Beacon, or even responding to ESSIDs not included in its Beacon, such behavior causes problems for many drivers. The Windows Zero Configuration software, for example, generally does not accept a configuration for a secondary, hidden ESSID. Rather than probing for the hidden ESSID, it attempts to attach to the transmitted ESSID in the Beacon.

When APs were first able to attach users to different VLANs, a common way of providing the configuration to users was to expose each VLAN as an SSID, and allow users to choose. While such an approach allows a great deal of flexibility in the way that users are assigned to VLANs, and allows them to switch between VLANs as circumstances dictate, the flexibility is a double-edged sword that may lead to confusion for users as they select the wrong configuration. Transmitting Beacon frames for a number of extra SSIDs requires the use of scarce wireless network capacity. For many environments, it makes more sense to dynamically assign users to VLANs based on a user profile database.

IP addresses are often a reflection of the physical network topology, and wireless networks are no different. Assigning IP addresses is a subordinate decision to the topology that you choose. Some network designs may require new address assignments and routing configuration, while others do not. Organizations that attempt to allocate address space hierarchically, perhaps for reasons of routing table size, may find it difficult to reconcile logical address assignment with the underlying physical topology. Furthermore, organizations that make use of registered IP address space may find that it is at a premium.

Users expect to be able to plug in to a network and just have it work. Wireless networks are no exception, and can make the problem worse. Users expect to be able to attach to any wireless network and have it just work. Practically speaking, the only way to have the IP stack for a wireless interface self-configure appropriately for an arbitrary number of networks is to use DHCP.

Many access points have built-in DHCP servers. Smaller networks consisting of an access point or two may choose to use the built-in DHCP service, but larger networks should have a single source of DHCP addressing information. Access point DHCP servers may not cope with the load very well, and some access points may reclaim leased addresses when an association lapses.

Any DHCP service should have a view of the total available address space, and this is best done outside the access point. Access points act like bridges, and pass DHCP requests from the wireless network through to the wired network, where a DHCP server can reply. With judicious use of DHCP helpers, a single server can support multiple IP networks, whether they are implemented as VLANs or multiple wireless subnets.

One of the challenges to wireless networking is that validating user credentials often depends on making a network connection to an authentication server. For example, Windows logins are validated against domain controllers. In a wired world, making that connection is trivial because the network is available whenever the cable is plugged in. In a wireless network, though, there is a bit of a chicken and egg problem. User credentials are used to authenticate the network connection, but a network connection is required to validate the user credentials. Not all operating system vendors have considered this problem. If yours has not, you may need to configure special login features or use additional client software to plug the gap.

In Figure 21-2, the network linking all the access points, which is often called the access point backbone, is a single IP subnet. To allow users to roam between access points, the network should be a single IP subnet, even if it spans multiple locations, because IP does not allow for network-layer mobility. (Mobile IP is the exception to this rule; see the sidebar earlier in this chapter.) Network-layer mobility is supplied by the use of a switching infrastructure that supports linking all the access points together, and an IP addressing scheme that does not require anything beyond link-layer mobility.

In Figure 21-2, the backbone network may be physically large, but it is constrained by the requirement that all access points connect directly to the backbone router (and each other) at the link layer. 802.11 hosts can move within the last network freely, but IP, as it is currently deployed, provides no way to move across subnet boundaries. To the IP-based hosts of the outside world, the VPN/access control boxes of Figure 21-2 are the last-hop routers. To get to an 802.11 wireless station with an IP address on the wireless network, simply go through the IP router to that network. It doesn’t matter whether a wireless station is connected to the first or third access point because it is reachable through the last-hop router. As far as the outside world can tell, the wireless station might as well be a workstation connected to an Ethernet.

If it leaves the subnet, though, it needs to get a IP new address and reestablish any open connections. The purpose of the design in Figure 21-2 is to assign a single IP subnet to the wireless stations and allow them to move freely between access points. Multiple subnets are not forbidden, but if you have different IP subnets, seamless mobility between subnets is not possible.

Older access points that cooperate in providing mobility need to be connected to each other at layer 2. One method of doing this, shown in Figure 21-3 (a), builds the wireless infrastructure of Figure 21-2 in parallel to the existing wired infrastructure. Access points are supported by a separate set of switches, cables, and uplinks in the core network. Virtual LANs (VLANs) can be employed to cut down on the required physical infrastructure, as in Figure 21-3 (b). Rather than acting as a simple layer-2 repeater, the switch in Figure 21-3 (b) can logically divide its ports into multiple layer-2 networks. The access points can be placed on a separate VLAN from the existing wired stations, and the “wireless VLAN” can be given its own IP subnet. Frames leaving the switch for the network core are tagged with the VLAN number to keep them logically distinct and may be sent to different destinations based on the tag. Multiple subnets can be run over the same uplink because the VLAN tag allows frames to be logically separated. Incoming frames for the wired networks are tagged with one VLAN identifier, and frames for the wireless VLAN are tagged with a different VLAN identifier. Frames are sent only to ports on the switch that are part of the same VLAN, so incoming frames tagged with the wireless VLAN are delivered only to the access points.

By making the access point backbone a VLAN, it can span long distances. VLAN-aware switches can be connected to each other, and the tagged link can be used to join multiple physical locations into a single logical network. In Figure 21-4, two switches are connected by a tagged link, and all four access points are assigned to the same VLAN. The four access points can be put on the same IP subnet and act as if they are connected to a single hub. The tagged link allows the two switches to be separated, and the distance can depend on the technology. By using fiber-optic links, VLANs can be made to go between buildings, so a single IP subnet can be extended across as many buildings as necessary.

Figure 21-3. Physical topologies for 802.11 network deployment

Figure 21-4. Using VLANs to span multiple switches

Tagged links can vary widely in cost and complexity. To connect different physical locations in one building, you can use a regular copper Ethernet cable. To connect two buildings together, fiber-optic cable is a must. Different buildings are usually at different voltage levels relative to each other. Connecting two buildings with a conductor such as copper would enable current to flow between (and possibly through) the two Ethernet switches, resulting in expensive damage. Fiber-optic cable does not conduct electricity and does not pick up electrical noise in the outdoor environment, which is a particular concern during electrical storms. Fiber also has the added benefit of high speeds for long-distance transmissions. If several Fast Ethernet devices are connected to a switch, the uplink is a bottleneck if it is only a Fast Ethernet interface. For best results on larger networks, uplinks are typically Gigabit Ethernet.

For very large organizations with very large budgets, uplinks do not need to be Ethernet. One company I have worked with uses a metro-area ATM cloud to connect buildings throughout a city at the link layer. With appropriate translations between Ethernet and ATM, such a service can be used as a trunk between switches.

Within the context of Figure 21-2, there are two places to put a DHCP server. One is on the access point backbone subnet itself. A standalone DHCP server would be responsible for the addresses available for wireless stations on the wireless subnet. Each subnet would require a DHCP server as part of the rollout. Alternatively, most devices capable of routing also include DHCP relay. The security device shown in Figure 21-2 includes routing capabilities, and some firewalls and VPN devices include DHCP relay. With DHCP relay, requests from the wireless network are bridged to the access point backbone by the access point and then further relayed by the access controller to the main corporate DHCP server. If your organization centralizes address assignment with DHCP, take advantage of the established, reliable DHCP service by using DHCP relay. One drawback to DHCP relay is that the relay process requires additional time and not all clients will wait patiently, so DHCP relay may not be an option.

Static addressing is acceptable, of course. The drawback to static addressing is that more addresses are required because all users, active or not, are using an address. To minimize end-user configuration, it is worth considering using DHCP to assign fixed addresses to MAC addresses.

As a final point, there may be an interaction between address assignment and security. If VPN solutions are deployed, it is possible to use RFC 1918 (private) address space for the infrastructure. DHCP servers could hand out private addresses that enable nodes to reach the VPN servers, and the VPN servers hand out routable addresses once VPN authentication succeeds.

This is the oldest of the architectures in this chapter, and pre-dates all the work done on link-layer security in the past several years. It is generally used on networks where link-layer security is not a priority, either because security is secondary to providing services (as in the case of an ISP) or because security is provided through higher-layer protocols with VPN technology. Security trade-offs in wireless network design are discussed in more detail in Chapter 22.

Depending on the existing backbone, using this topology may require prohibitive work on the backbone, or it may be relatively easy. For maximum mobility, every access point must be attached to the wireless VLAN that snakes throughout the campus. If a network is built on a switched core, it may be relatively easy to create a VLAN that spans multiple switches across several wiring closets. However, there may be fundamental limitations on what is possible. If buildings are separated by routers, it may not be possible to build a single VLAN that spans an entire campus, and it may be necessary to settle for disjointed islands of mobility. Even worse, many older networks are not built around switched cores that allow easy VLAN extensions everywhere.

Furthermore, there is a practical limitation on the network diameter of a VLAN. 802.1D, the bridging standard, recommends that VLANs be built with a maximum diameter of seven switch hops. Depending on the physical topology, it may be impossible to build a single VLAN that can span the desired coverage area within the recommended limit. Alternatively, it may be possible to do so, but only with extensive modifications to the network core.

Performance of this design can vary greatly because it incorporates a single choke point. One of the most important aspects of making this design perform well is limiting the effect of pushing all the traffic through a single logical path. All the backbone devices must have sufficient capacity to handle the load from the entire wireless network.

Wireless LAN protocols are based on collision avoidance, and can sustain much higher loads than the collision-detection protocols used on wired LANs. Depending on the number of users associated with a particular access point, it may be reasonable to assume that the radio link is saturated. Maximum throughput rates vary slightly from product to product, but 6 Mbps is a reasonable maximum rate for 802.11b, with 802.11a and 802.11g both weighing in at 27-30 Mbps.

Avoiding congestion is much easier with the slow speeds of 802.11b. With only a 6 Mbps potential load per access point, a full duplex Fast Ethernet links to the access point backbone should be able to handle slightly over 30 APs. While 30 APs is not a monstrous network, it is enough to provide blanket coverage over a large open space for low-bandwidth applications. Upgrading to Gigabit Ethernet on the choke point vastly increases the number of APs that can be attached. Depending on the breakdown between upstream and downstream traffic, it is possible to connect 200-300 APs without worrying about backbone network congestion. Of course, gigabit choke point devices cost significantly more than Fast Ethernet choke point devices.

802.11a and 802.11g, with their potentially higher speeds, could pose more of a problem. With several times the speed, only a few access points can saturate a Fast Ethernet choke point. Assuming a favorable breakdown between upstream and downstream transmission, full duplex Fast Ethernet can connect six APs, which is not enough to cover many midsized offices. Dual-band APs that do both 802.11a and 802.11g present a double whammy because each radio may offer a high load.

Table 21-3 summarizes the discussion of backbone technology and the number of APs required to saturate the link. It is meant only as a “back of the envelope” estimate. Each backbone technology is divided by the AP-offered load to estimate the number of APs required to saturate the link. It does not take into account any protocol overhead or realistic split between upstream and downstream traffic. It is meant as a rough guide to select an appropriate uplink technology from your wireless subnet.

This is the most varied of the architectures in terms of client integration. In the case of a service provider, it is likely that little or no client work is required. No security of any sort is applied, so there is nothing to configure. If extensive higher-layer security is applied on top of this architecture, however, there is extensive desktop integration to be done.

The single-subnet architecture achieved mobility by creating a single subnet for all access points, and keeping all the users on the that restricted subnet. This architecture borrows the same philosophy, but is designed to work with networks that are not able to create a single subnet.

At the most basic level, this architecture provides portability. Users can move between islands without restriction, but need to reestablish any open network connections as they move between islands. Connection reestablishment may be handled in a variety of ways, some of which may be transparent to the user. Many universities simply accept the limitations of portability, and instruct users to close any applications that use network resources before moving. If portability limitations are problematic, it may be possible to achieve mobility between IP networks by using client software or tunneling protocols.

This topology looks much like the first topology, except that it is replicated in several pieces. Most likely, the islands of connectivity connect to the network core through firewalls. Mobility between islands may be achieved by using a tunneling protocol that ensures that a user attaches to the same logical location on the network, no matter what their physical location.

Figure 21-6 shows how mobility can be grafted on to a collection of scattered networks. In Figure 21-6 (a), clients are given a local IP address that is tied to location. The local networks are represented by Net X and Net Y. Upon connection, clients are issued addresses from the IP space assigned to the X and Y networks. However, the client also initiates a connection to a central concentration point. Clients logically attach to the concentrator, and receive an address from a network logically attached to the concentrator, which is denoted by Net Z in the diagram. Packets sent from the client use its central anchor point address, Z, as the source, but they are bundled into a tunnel for transmission. Replies are routed back to Z, but the concentrator maintains a mapping of addresses on network Z to location-based addresses. Note that Figure 21-6 (a) does not specify any particular tunneling method. Mobile IP works in essentially this way, and a few specialized IPsec clients work this way as well.

Although the approach of Figure 21-6 (a) is conceptually straightforward, it requires changing the software on all wireless devices. In addition to the administrative challenge of loading new software on any wireless device and the potential instability of changing the network stack, it is likely that vendors of this software would not be able to support every operating system platform. Even if the major operating systems were supported, many embedded devices could not be. Figure 21-6 (b) offers an alternative approach where the tunneling is moved into the network. In Figure 21-6 (b), access points do not connect to a backbone network for the purpose of delivering traffic. The backbone network is used only to connect APs to the traffic concentration point. Any frames or packets from the client are delivered through the tunnel to the concentrator device, where they are sent on to the rest of the network. It does not matter where clients attach to the network because traffic is always routed to the traffic concentration point.

In both of the cases in Figure 21-6, the key is that client IP addresses become location-independent. IP addresses on local networks are used for the purpose of connectivity, but the logical point of attachment to the network is through a defined anchor point, just as in the previous topology.

Tunneling approaches work to unite disjointed coverage areas. In the first topology, mobility was all-or-nothing. Figure 21-5’s disjointed coverage areas force network architects to design mobility around areas that are most important to users, subject to the constraints of the local network design. By using a tunneling approach, the network can be reunited into a single mobility cloud, but without the need to re-engineer the entire network backbone. There is, however, the difficulty of configuring any tunneling and working out the overlay topology.

Figure 21-6. Mobility through tunneling

One of the advantages of this architecture is that it is easy to use it with IPsec. IPsec is a suite of strong, trusted encryption protocols that have been widely used in hostile network environments, and that trust has allowed IPsec to be used to protect a great deal of sensitive information traversing the Internet. Many organizations that have a need to protect private personal information make extensive use of IPsec.

One drawback to relying on network-layer security is that it gives malicious attackers a foothold on your network. If association to the network is not protected, then attackers may obtain a network address and start launching attacks against against other clients or the network infrastructure outside the firewall. Strong firewall protection is a must to contain any attacks originating on the untrusted network. Host security is also extremely important because devious attackers would also likely attempt to subvert host security on the clients to hijack VPN tunnels, so personal firewall software is a must.

IPsec was designed with a point-to-point architecture in mind. When used between major sites, traffic is inherently point-to-point. However, LANs are not meant to be point to point networks. (Just ask anybody who has experience with ATM LAN Emulation!) Applications that make use of multicast will probably not work with IPsec without modification or network reconfiguration.

Providing connectivity through isolated islands gives this topology a distinct advantage over the first topology. Rather than one gateway device that handles all traffic from the wireless LAN, each island gateway must be capable of fowarding only that island’s traffic. Multiple choke points between wireless and wired networks allow each choke point to be a smaller, and therefore less expensive, device.

This architecture is frequently used with IPsec, often with an existing VPN termination device. One problem that can occur is that VPN devices are often sized for remote user termination. If LAN users suddenly start using IPsec, the existing VPN termination device may prove inadequate. A centrally located VPN device must be able to provide encryption for the entire wireless LAN traffic load; each 802.11b access point may offer a traffic load of up to 6 Mbps each, while an 802.11a or 802.11g access point may serve up a load approaching 30 Mbps.

There are many different tunneling options available for this broad topology. Tunneling always imposes a network overhead because it requires encapsulation. An additional challenge that wireless LAN devices must face is the need for fragmentation in tunneling protocols. Many of the LAN backbones used to connect access points do not support jumbo frames, so any tunneling protocol that runs over Ethernet must incorporate fragmentation and reassembly. Beyond the fragmentation overhead, any tunneling protocol requires additional header information. Depending on the protocol selected, fragmentation overhead may be nontrivial.

Running user traffic across a network backbone may diminish the service quality. Large networks may not be able to provide consistent low-latency forwarding performance between the access points and the concentration device, especially if the tunneling mechanism is implemented over a best-effort protocol like IP. In the case of user data traffic, any service quality diminishment is likely to be negligible. If the wireless network must be used to support voice protocols, however, the impact of tunneling may be more substantial.

Compared to the single-subnet architecture, this topology integrates much better with networks that cannot support a single VLAN everywhere. At worst, this architecture requires creating several miniature single-subnet backbones. If tunneling functions are moved into the network, though, it is possible to extend networks out to remote locations without any backbone work.

VPN software is typically used with this approach, which requires configuring client software on any machine that will use the wireless network. In some organizations, this may not represent a large burden, especially if most of the users already have VPN software. However, many organizations limit the number of users given remote access privileges to limit the amount of client integration work necessary, or prevent remote access devices from being overwhelmed with the load. If you work for such an organization, there is a significant client software installation burden with a widespread wireless deployment. As mentioned previously, personal firewall software is mandatory to protect each client from link-layer attacks. Give preference to VPN clients that include personal firewall software, especially if the personal firewall policies can be centrally managed.

At the highest level, mobility in this topology is identical to the first topology. Users are attached to a consistent VLAN throughout the network, and thus can maintain the same IP address regardless of location. With the same IP address, any transport-layer state or application state remains valid throughout the life of the connection.

However, the underlying implementation of mobility offers several advantages over the single-subnet architecture. The first set of advantages have to do with the use of authentication services. Attributes from the RADIUS server ensure that users are always attached to the same VLAN, and hence, they stay attached to the same logical point on the network.

In addition to aiding mobility, providing consistent VLAN attachment can make other services work better. Providing mobility at the link layer reduces the apparent mobility to higher-layer protocols, and hence, the amount of work required of them. IPsec tunnels stay up consistently because the IP address does not change. Likewise, Mobile IP location updates are not necessary because the IP address is maintained.

Because the VLAN assignment is based on 802.1X and RADIUS, security in this topology is based on dynamically generated keys at the link layer, either through dynamic WEP, WPA, or CCMP. Dynamic key generation enables the second benefit of using authentication services. Once users have been identified, they can be separated into groups for different security treatment.

To separate traffic in the air between user groups, access points use multiple key sets. Upon authentication, every user is given a default (broadcast) key, and a key mapping (unicast) key. Broadcast domains are defined by the stations in possession of the same broadcast key. In Figure 21-8, the two users on the left are part of the same user group, and share the same broadcast key. When one sends, say, an ARP request, the other responds. Users who are part of a different broadcast domain are not able to decrypt and process the frame because they have a different broadcast key. Although user groups share the same radio capacity, they are not members of the same user group and remain separated over the radio network.

Figure 21-8. Broadcast separation by keys

Furthermore, the separation of user groups by VLAN allows the application of differentiated services, as shown in Figure 21-9. One common use of user identification and differentiation is to offer guest services. Internal users are identified and authenticated against a user database, and then connected to the internal network. Guest users do not have accounts on the main user database and cannot authenticate to the network. After failing to do so, they are attached to a different logical network. Guest networks may have “splash pages” that require a click-through agreement to not abuse the network; some organizations may also wish to require payment for guest access.

Figure 21-9. Differentiated user services

An additional advantage to link-layer security is that multicast is well-integrated into the security protocol. LAN protocols often make heavy use of multicast or broadcast frames, and the use of multicast LAN frames can only increase. Wireless networks are attractive because of their flexibility and location-independence. Protocols that assist in the automatic discovery and configuration of new devices usually rely heavily on multicast frames.

One downside to this topology relates to bureaucratic requirements around security. At the time this book was written, link-layer security could not comply with FIPS-140, the U.S. federal government’s network security standard, because of a subtle flaw with the dynamic key derivation algorithms in 802.11i. Although the encryption mode used by CCMP is approved, a small change to the key derivation algorithm is likely to be required before 802.11i-based networks can meet the FIPS-140 bar.

This architecture does not necessarily require a choke point. Switching frames at the network edge eliminates the requirement for an oversized packet forwarding device. Wireless LANs are access networks, so by definition, a wireless LAN should not be able to overload a well-built network core. One of the downsides of this architecture, however, is that it is best deployed around a big, fast switched core.

Redesigning a network to use VLAN information dynamically can often impose a substantial redesign of the the network backbone. What is required depends on how the wireless LAN connects to the network core. When a wireless LAN connects to the core to attach users to multiple networks, it typically uses an 802.1Q tagged link. Wireless LAN products vary in how widely tagging is used, and to what extent the tags must be pushed across the network. In broad terms, there are two major ways to push VLAN information out to access points.

Of the two methods, tunneled connections tend to impose less of a backbone engineering requirement because tags can be distributed on a more local basis. In the direct connect case, every port connected to an access point must carry the complete set of VLANs users may want to work with. The backbone impact is just as great as the first topology for each VLAN. In contrast, indirect connections can span wider areas by operating outside of a spanning tree domain, and configuration of individual switch ports may be easier.

802.1X supplicants are now built-in to the most common client operating systems. Windows 2000, Windows XP, and Mac OS X 10.3 all have 802.1X supplicant software built into the operating system. Provided that you wish to use one of the authentication protocols supported by the operating system’s supplicant, there is no client installation to worry about. Furthermore, the built-in supplicant configuration can often be assisted by the use of large-scale system administration tools to distribute the required certificates or configuration information.

This topology provides essentially the same mobility as the previous topology. VLANs can be dynamically instantiated at the edge to connect users, so client stations are dynamically attached to the correct point on the network. As in the previous case, additional protocols may be used to extend mobility across more than a single VLAN domain.

With virtual access points, limiting mobility may be important. This architecture is designed around providing service, and it may be that service should not be ubiquitous. If an office building were to provide connectivity for tenants, the owners may choose to limit where tenants can connect. Rather than connecting anywhere in the building, the service may be limited to a particular floor or wing. If an airport were to deploy a network using virtual access points, the public hot spot service providers would likely be restricted to the public areas, while the airport operational network was available through more of the facility. Different products provide alternate approaches to limiting mobility. As with many other network control functions, your preference should be for centrally-administered access controls.

Due to the tie-in with the link layer, this topology is often used in conjunction with 802.1X and RADIUS. 802.1X should not be a requirement. Each of the virtual networks should have its own security configuration, which would allow every customer to enforce their own security policy. Different customers may have different requirements, and a network built on virtual access points should accommodate any reasonable security policy. For example, most hot spot providers are running web-based login systems. While a web-based login system may be good enough for some applications, legal requirements would impose much stricter handling on a system that accessed personally-identifiable information. Virtual AP-based networks need to accommodate both types of access simultaneously.

Performance is not constrained by a choke point anywhere. With the wireless network connecting directly into a larger network core, the only performance constraint is congestion on the core.

The biggest problem facing a multitenant network is that the network owner has to design a network with enough capacity for all the users. In the case of a private network owned and operated by one organization for its own purposes, it may be possible to estimate the network requirements. With a network service provided to others, the estimates obtained by consulting with users may be somewhat murky.

One additional item worthy of note is that analyzers may report overloaded channels because a single AP acts as multiple virtual APs. Provided that the network has been designed around the total throughput required by all users, it is acceptable to have multiple networks over the air.

Like any other AP, a virtual AP connects a radio network to a wired network. In the case of a virtual AP, both the radio and fixed networks may be created over a shared physical infrastructure. Rather than one wired network, or a set of networks owned by one organization, there may be a need to connect to several customer networks on the back end. When all the networks belong to one organization, they probably have similar security requirements and can be connected easily to wireless networks. Mapping wireless networks on to the wired networks of several different (and possibly competing) customers may require additional measures to ensure security and traffic separation.

As with the other topologies, the client software load depends a great deal on the security protocols. At the easy end of the spectrum, a network can be deployed using web-based authentication without requiring any client software. At the most difficult, the network can use several security protocols, each with its own client software requirement. One of the advantages to virtual AP-based networks is that the virtual APs may be used to create several networks, each with its own special security configuration.