Evaluating a Logical Architecture

Before presenting any topologies in detail, I will discuss how to evaluate a proposed network. Each of the topologies presented in this chapter has its own strengths and weaknesses. Choosing a topology depends on which criteria are compelling on your network. Here are discuss several evaluation criteria that I have found to be important.

Mobility

Portability results in a productivity gain because users can access information resources wherever it is convenient to do so. At the core, however, portability removes only the physical barriers to connectivity. It is easy to carry a laptop between several locations, so people do. But portability does not change the ritual of connecting to networks at each new location. It is still necessary to physically connect to the network and reestablish network connections, and network connections cannot be used while the device is being moved.

If, for example, you have a remotely mounted filesystem and put a laptop to sleep, it may not be there when the laptop wakes up in a different location. Any open files or activity against the filesystem may need to timeout before you can regain control of the computer. DHCP clients may impose more pedestrian restrictions. Common DHCP clients attempt to renew the lease on the last address obtained, and may need to go through multiple DHCP exchanges to get an address on a new IP subnet.

Mobility, on the other hand, is a far more powerful concept: it removes further barriers, most of which are based on the logical network architecture. Network connections stay active even while the device is in motion. This is critical for tasks requiring persistent, long-lived connections, which may be found in database applications. Support personnel frequently access a tracking database that logs questions, problems, and resolutions. The same argument can be made for a number of tracking applications in a health care setting. Accessing the database through a wireless network can boost productivity because it allows people to add small amounts of information from different locations without needing to reconnect to the database each time. Inventory applications are another example and one of the reasons why retail and logistics are two of the markets that have been quicker to adopt 802.11. When taking inventory, it makes far more sense to count boxes or products where they sit and relay data over a wireless network than to record data on paper and collate the data at the end of the process.[*]

[*] Indeed, the early adopters of wireless LAN technology tended to be in organizations where the work was mobilehealth care, logistics, and education.

Traditional wired Ethernet connections provide portability. I can take my laptop computer anywhere on the campus at work and plug in. (If I'll tolerate slow speeds, I can even make a phone call and access my corporate network anywhere in the world.) Each time I access the network, though, I'm starting from scratch. I have to reestablish connections, even if I only moved a few feet. What I'd really like is to walk into the conference room and connect to the corporate network without doing anything.

Defining "mobility"

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.

1. Consistent MAC-layer attachment to the same link-layer network. Mobility requires that the existing data-link layer look the same regardless of location. Extensive engineering in 802.11 provides link-layer mobility.
   1. Transparent handoffs between access points. Users may need to perform an initial configuration operation to select a network to connect to, but they should not be involved in handoff decisions. If the signal strength gets too low, the software should attempt to locate a better signal and transfer to it without user intervention. Every wireless card I am aware of currently switches between access points that are part of the same network. 802.11 was designed around this requirement, and any piece of wireless LAN equipment you buy should have no trouble meeting it.
   2. The inter-access point handoff can break down when the access points are located in different broadcast domains. If two stations are exchanging frames and one moves to a new access point, 802.11 cannot guarantee that the two stations stay attached to the same broadcast domain. One opportunity for vendors to improve on 802.11 is to link access points with the same SSID together so they no matter where they attach to the network, stations in the wireless LAN attach the same broadcast domain everywhere, even if the access points are connected to different local broadcast domains.
   3. Moving a client system between two access points also requires either setting up a new set of security parameters for encryption and integrity protection, or transferring security parameters from the old access point to the new access point. 802.11 does not specify either procedure. Depending on the hardware in use, the process of establishing a security context with the new access point can take a fair amount of time. In bulk data transfer, the blip may not be noticeable; for voice conversations, it often is.

2. No configuration changes are required to the client network stack. For the most part, this means that clients can maintain the same network address as they move throughout the network. In most networks, the address is an IP address, although there may be some applications that require maintenance of other network protocol addresses as well. Extensive engineering has been devoted to network layer mobility, especially in the IP world, which traditionally has not provided it. Address maintenance is a major network engineering challenge, especially if it is required across what would otherwise be an IP subnet boundary.
   1. Before maintaining an address, the client must obtain one. At the initial connection to a wireless LAN, the system should somehow get an address, most likely through DHCP. That address should be used for the duration of the wireless LAN session. From the client's perspective, it keeps the IP address as it moves through the network, and does not need to alter its address or any other stack information to attach to any new access points.
   2. Wireless networks can have brief interruptions of connectivity as clients move between coverage areas or suffer from transient radio link problems. For brief interruptions, access points should maintain enough session information so that the client can simply rejoin the network. Access points may also need to buffer frames so that clients can fetch any traffic that was received during the interruption.
   3. Equally important, the client must appear to maintain its address. If the client connects to a server somewhere, the server should be able to use the same address for the duration of the connection. Furthermore, any other state the network maintains is often associated with an IP address. Many networks use NAT to reach the Internet, and the NAT records are associated with the client IP address.
   4. Depending on the application, it may be necessary to have logical network path preservation. Transmitted frames must always emerge from the same egress point on the network, so they are subject to whatever controls the network requires. No matter what the location of the client throughout the network, it always appears as if it is attached to the same point at the edge of the network.

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).

Security

As the networks of the world have united into a single, globe-spanning behemoth, security has taken on new importance. Wireless LANs were once the bane of security-conscious networking organizations, but newer tools make it easier to build networks with significant security protections. In addition to traditional security issues such as traffic separation between user groups and maintaining appropriate access privileges, wireless networks present new challenges, like rogue access points and unauthorized clients.

Many of logical architecture's security ramifications are related to the selection of encryption and authentication protocols. But the architecture may have some additional security implications based on technology available at the edge of the network.

Traditional access points are autonomous devices that act as independent network elements. Access points are placed out in user areas, and are usually not physically secured. Unfortunately, the popularity of 802.11 may make unsecured access points in public areas targets for theft. Traditional access points have local software and configuration, and may also be attractive targets to attackers who can use learn sensitive security information from the configuration, such as the RADIUS shared secret. Newer "thin" access points help address this concern by removing a great deal of functionality from the access point and pulling it back into secured controllers that can be locked away in wiring closets.

Attackers may also remove access points to obtain additional network privileges. In some architectures, access points must be connected to relatively privileged network ports. If, for example, several VLANs are made available through a wireless network, many access points require that the access point connect to a link tagged with all the available VLANs. In such a setup, an attacker may obtain direct access to the backbone by removing an access point and connecting to its port.

One additional concern is that many government networks need to be designed to comply with regulations and best practices. The National Institute of Standards and Technology (NIST) is responsible for developing many of the computing standards used by the U.S. federal government; these standards are referred to as Federal Information Processing Standards (FIPS). One particular standard, FIPS-140, lays out requirements for secure network designs. Not surprisingly, FIPS-140 specifies that certain types of data must be encrypted. Less obviously, FIPS-140 also requires that approved encryption algorithms and modes must be used. Not all security protocols and standards are created equal, and only some network designs are capable of meeting FIPS-140 criteria. FIPS requirements affect most federal agencies, but may also exert a powerful influence by requiring compliance on the part of an agency's suppliers and contractors. (FIPS requirements are discussed in more detail in Chapter 22.)

Performance

For the benefit of mobility, wireless networks impose a cost. Simply, performance is nowhere near what can be expected from a well-engineered wired LAN. Wireless networks have smaller advertised bit rates than wired LANs. To make matters worse, the big number in the glossy brochure omits a great deal of protocol overhead.[] Table 21-1 gives rule-of-thumb estimates for the maximum throughput based on the technology.

[] The effective throughput is actually much lower. Quantifying the exact impact of the protocol overhead is very difficult; for one straw-man calculation, see http://www.oreillynet.com/pub/a/wireless/2003/08/08/wireless_throughput.html.

Unlike wired networks, the speed at which wireless networks operate depends on the distance from the nearest network uplink. As stations move farther from the serving access point, signals become weaker and the operational speed falls. Throughput depends on distance from the access point and the position of the device in a way that is unfamiliar to users of wired networks.

Throughputs in the neighborhood of Table 21-1 require very strong signals, and by necessity, limited distances from the access point. As a practical matter, most wireless LANs have been built for coverage. At the fringes of connectivity, throughput is at the lowest rate for the technology, not the highest rate. Figure 21-1 illustrates the typical scenario. Although stations close-in connect at the maximum data rate, stations that are further away require much longer time intervals to transmit the same data. Even if the radio medium is in constant use, the maximum throughput of the stations associated to the AP in Figure 21-1 would be much less than 6 Mbps.

Even though the maximum data rates shown in Figure 21-1 are small, the magic of statistical multiplexing can make the rate seem much bigger than it is. Networks are based on the principle that user traffic is often quite bursty. Although users demand a peak data rate of a megabit per second, users are often idle. The network only needs to supply the peak data rate during email fetches and web page downloads; when the connection is idle, other users can get their megabit per second service. In my experience, a multiplexing factor of between 3:1 and 7:1 can be used to account for the burstiness of network traffic. Although an 802.11b network may only deliver 6 Mbps, it can accommodate 20-30 users demanding megabit service because very few applications require continuous service. (Voice applications are a notable exception.) The last column in Table 21-1 shows the effective throughput with a 5:1 multiplexing factor. Depending on applications and experience, you may need to use a higher or lower factor on your network.

Figure 21-1 is only a qualitative display of how the speed of a network changes with ditsance. Free-space loss calcuations can be used to get a more quantitative grasp of a network's range and propagation characteristics. Free-space loss, or path loss, is the transmission loss over space, with no obstructions. It is an "ideal" number, describing only how the electromagnetic waves diminish in strength over distance while neglecting a number of factors that are relevant to building 802.11 networks. Indoor networks must deal with walls, windows, doors, and the fact that many signals may not be line of sight. Free-space loss calculations assume the noise floor is also sufficiently low that the receiver sensitivity is the limiting factor. In many environments, the number of unlicensed devices operating in the 2.4 GHz ISM band push up the noise floor well past the lower limits of many receivers.

Figure 21-1. Dependence of performance on range

Free-space loss depends only on two inputs: the frequency of the signal and the distance it must cover. Higher frequencies attenuate faster, as do longer distances.

Table 21-2 is based on a free-space calcuation for both 2.4 GHz and 5 GHz wireless LANs. For the ISM frequency, it uses 2.437 GHz, the center frequency of channel 6. For the 5 GHz frequency, it uses 5.250 GHz, which is the midpoint of the U-NII lower and mid-bands. (Some early 802.11 cards were only able to function in the two low bands, so some networks restrict 802.11a channel usage to the first 8.) It assumes that power is transmitted at the maximum of 20 dBm (100 mW) in the 2.4 GHz band, and at the maximum practical power of 14 dBm (25 mW) for many 802.11a devices. For a receiver cut-off, the sensitivity listed on the data sheet for the Cisco CB-21 a/b/g client card was used. By using the sensitivity directly, it is an implied assumption that the noise floor is significantly below the values listed in the sensitivity column. Do not expect to get the ranges noted in this table, since it is only a calculation of the maximum ideal range. It is, however, a useful guide to comparing different modulation rates as well as the different frequency bands in use.

The performance of a wireless network differs from a wired network in another important way. Most wireline networks are built using switches, so multiple independent traffic flows can be switched independently. Wireless networks are inherently a shared medium. Within an access point's coverage area, only one client may transmit data. Wireless networks often are built simply to cover an area. As they become popular, network administrators must add capacity by shrinking the coverage area of individual APs to reduce bandwidth contention. Limiting bandwidth contention by making coverage areas smaller is the approach taken by most "Wi-Fi switches."

Physical characteristics of the wireless medium negatively affect performance and service quality. 802.11 uses a fully-acknowledged MAC for reliability, but the need for acknowledgments increases the transmission latency for frames. Lost packets and the potential for retransmission may also increase the variability in latency, called jitter. For some applications, the difference in service is imperceptible to the user. Bulk data transfers depend much more on available capacity than the service quality. However, if you plan to run voice on your wireless network, you will need to spend some time engineering acceptable service quality. Voice depends on regular delivery of small amounts of data, not high throughput. Some of the architectures discussed in this chapter are better suited to applications with demands for high quality network service.

Traditional quality of service queuing and controls are important not only because of the need to cope with the relatively low reliability of wireless signals, but also because the bandwidth is so limited. With only a few megabits per second on each access point, a single ill-behaved client can soak up all the available capacity. Some access points provide better traffic shaping and policing to engineer allocation of scarce wireless medium capacity than others, and some logical architectures are better able to cope with high-bandwidth applications.

As with many other network engineering tasks, building a wireless LAN with the necessary performance is a matter of analyzing the types of applications you intend to run on the LAN and removing as many bottlenecks as possible. In some cases, it may be possible to build enough network capacity to provide the required user experience. For other applications, it may be necessary to manage resource allocations using traffic management tools on the access points making up the network.

Backbone Engineering

Access points are the edge of the ever-expanding network. In most cases, they do not offer new network services; they just make existing services more widely available and easy to use. As edge devices, though, they must plug into a network core to interconnect users with resources. Expect to do some additional configuration of the network core when wireless is added to the edge of the LAN.

When 802.11 was a new standard and products had just emerged, there was no mobility except for what the network engineers created, and no traffic separation at all. Mobility was entirely up to the network engineer. If the access points could be placed in a single link layer network, mobility existed. If not, mobility remained elusive. Early wireless LANs required, as a matter of practice, that the network be built around a switched core so that a single subnet snaking through the entire campus could be used to connect up all the access points. Many newer networks are built around a switched core, but older networks frequently have constraints that prevents building a purely switched core.

After the first wave of products arrived, the industry produced devices that could attach users to multiple VLANs. Although these products allowed for multiple user groups over the air and the backbone wire, the backbone configuration impact was even larger. Rather than extending a single VLAN through the campus for the access points, every VLAN had to be extended to every access point throughout the campus. One of the goals of centralized Wi-Fi controllers is to further reduce backbone reengineering by allowing for simpler configurations of the access device connections.

Beacons, BSSIDs, and VLAN integration

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."[*] 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.

[*] This is a bit of a simplification. ESSIDs are only network names for infrastructure networks. As always, this book generally assumes that you are running an infrastructure network, not an ad hoc network.

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 addressing

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.

Network Services

Ideally, new network devices should plug into existing infrastructure and just work with a minimum of reconfiguration. A few network services are important to the user experience, and should be considered in some detail.

DHCP

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.

Operating system login

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.

Client Integration

Different logical architectures require different client software support. It is easy to build a network that has no client integration beyond the new drivers by leaving out security entirely. However, security is a requirement for nearly every network.

The most basic level of security is a static WEP key. Some older devices may not support anything better than static WEP, in which case you are stuck with it in the absence of a forklift upgrade. Static WEP configuration is typically built into driver software or client configuration utilities, and requires no more client integration than using the card itself. For security reasons, though, you want to run something other than static WEP if at all possible.

Link-layer solutions based on 802.1X offer significant advances in security, but require more sigificant client integration work. 802.1X supplicant software must be loaded on the client system and set up correctly. Supplicant software is incorporated into recent operating systems (Windows 2000, Windows XP, and Mac OS X 10.3). Older systems may require a client software package to implement 802.1X.

VPN solutions vary, depending on both the vendor and the type of VPN technology. SSL-based VPNs work by directing client access through a secure web site that acts as a portal for applications. Because the technology is based on a secure web site, there is no client installation beyond the web browser that probably is already installed on most systems. One downside to SSL VPN technology, however, is securing non-web applications may require additional effort and user retraining. IPsec VPNs require a much more disruptive software installation, but are much better at handling an arbitrary IP-based application. One of the reasons that VPN client software loads are more complex is that most vendors require their own VPN client for maximum functionality between the client and gateway.

Some organizations may be limited in their ability to impose client software on users. Universities, for example, often have users who must open VPN tunnels to external network sites. Professional development classes are often taken by students who have careers, and may need to connect to corporate resources from the classroom. Generally speaking, IPsec tunnels inside IPsec tunnels with multiple clients is a configuration that does not work well, if at all.