Building a “micro-network” of a AP or two is easy. With a small number of APs, it is acceptable to manage APs individually. Upgrading to 802.11n is also straightforward: take out your existing 802.11a/b/g APs and replace them with 802.11n APs. At such a small scale, almost anything will work. That is, unless your micro-network is actually one small piece of a larger network, in which case you should skip ahead a couple of sections and start reading. At some point, the overhead of managing individual devices will be too great, at which point you are building a small- or medium-size network. These networks have just as much to gain from 802.11n. Building a small network of five to ten APs is too small to use the “big iron” of controllers, but it is large enough to require centralized management.

Prior to the widespread use of 802.11n, large networks needed a centralized control plane to handle the loads imposed by large numbers of users, and the choice between autonomous APs and controller-based APs was a straightforward one that was almost always resolved in favor of the more advanced centralized control plane. 802.11n enabled a change in user attitudes towards connectivity that has driven the development of distributed control planes. As wireless LANs became viewed as stable, many new devices are being built without Ethernet—the MacBook Air was one of the first examples, and the number and variety of tablet devices is another. With users switching towards mobile battery-operated devices that they can use on the go, a significant portion of the network access layer has moved from traditional wired Ethernet to wireless networks. With the explosion of 802.11 devices now available, network architects have designed higher- and higher-capacity networks, stressing the centralized control plane. Early controller-based networks were able to use a single controller as the focal point for both the control and the data plane, but that assumption no longer holds.

Table 8-1 compares the three basic architectures. In reality, there is some overlap between these architectures when they are implemented in products. It is likely that a large-scale network at any speed, especially one supporting critical applications, will require some degree of decentralization, either by moving some of the data plane functions to the edge of the network, some of the control plane functions to the edge of the network, or both. All three architectures are capable of supporting any set of network requirements, but the cost and availability of the resulting network may vary.

Data plane

This section has presented each of the three architectures with sharp lines between them. In actual products, the location of data forwarding is one of the places where products offer flexibility. Many controller-based APs can be configured to send data either through a centralized controller or directly from the AP to the network. Some common hybrid approaches are to offer a choice on a per-SSID basis so that guest traffic can be centrally forwarded, or that traffic from devices attached to the AP’s VLAN can be forwarded by the AP while traffic bound for VLANs attached to other APs must be send through the controller’s forwarding engine. Likewise, some distributed data planes offer roaming capabilities that can make any VLAN accessible throughout the network by tunneling between APs.

When a centralized data plane is used, 802.11n APs may also benefit from jumbo frame support and path MTU discovery. In the centralized forwarding model, illustrated by the top AP in Figure 8-3, data frames from client devices are transmitted from the AP to the controller through a tunnel that traverses the network backbone. For a transmitted frame to be sent to its network destination, it is received by the AP, passed to the controller through the tunnel, and then placed on the network by the controller.

Figure 8-3. Jumbo frame support

For efficiency, client devices generally send maximum-length Ethernet frames of 1,500 bytes. Unless the path between the AP and controller can handle jumbo frames, it will have to fragment client traffic, resulting in a 1,500-byte frame that contains most of the client’s frame, followed by a second frame that has the remainder of the client’s data. There are four main ways to cope with the potential for fragmentation in a controller-based architecture:

Jumbo frame support

If the path between the AP and controller supports jumbo frames, nothing happens. The AP takes the client’s data frame, puts a tunnel header on it, and sends the slightly larger tunneled frame across the network. There is an theoretical (and, in practice, imperceptible) penalty in speed because the tunneled frame is slightly larger, but the overhead is so minimal that I doubt any real-life network has measured the performance impact.

IP stack fragmentation

IP itself can fragment frames. When the client data frame comes to the AP, it is given a tunnel header, and the resulting packet for transmission to the controller exceeds 1,500 bytes. As a result, the IP stack will fragment the packet into a maximum-size packet plus a fragment. When both the first packet and its trailing fragment arrive at the controller, they are reassembled into a single IP packet, the tunnel header is removed, and the client’s data frame is processed. Using IP-level fragmentation takes advantage of existing fragmentation code that is well-understood, but it does impose a cost on the controller in terms of packet buffer memory and processor load; the backbone must also forward two packets instead of just one. Depending on the network architecture, the tunnel may also break; most firewalls drop all IP fragments without further analysis.

Controller tunnel (CAPWAP) fragmentation

As an alternative to using fragmentation and reassembly in the IP stack, the tunneling protocol between the AP and controller can implement its own fragmentation protocol. In fact, the Control and Provisioning of Wireless Access Points (CAPWAP) protocol, specified in RFC 5415, specifies its own fragmentation layer (see section 3.4). Fragmentation at the tunneling protocol improves firewall traversal because most firewalls do not perform detailed analysis of traffic beyond IP headers.

TCP Maximum Segment Size control

The initial setup of a TCP connection includes a Maximum Segment Size (MSS). Some APs can rewrite the MSS value sent by clients so that the clients send frames that are small enough that the client frame plus the tunnel header is exactly the maximum size packet for the AP-to-backbone connection.

Additionally, there is one additional way to connect APs to the backbone network to avoid fragmentation concerns. Instead of using a tunneling protocol to reach a central point of attachment, some APs can connect directly to the network edge and forward traffic through the edge switch, as illustrated by the bottom AP. APs that support direct connection to the network do not require jumbo frame support.

Many commercial products on the market offer a combination of the approaches in Figure 8-3. Some controller-based APs can be configured to send data either through a centralized controller or directly from the AP to the network. Some common hybrid approaches are to offer a choice on a per-SSID basis so that guest traffic can be centrally forwarded, or that traffic from devices attached to the AP’s VLAN can be forwarded by the AP while traffic bound for VLANs attached to other APs must be send through the controller’s forwarding engine. Likewise, some distributed data planes offer roaming capabilities that can make any VLAN accessible throughout the network by tunneling between APs.

Note

With an 802.11n network of any size, it is likely you need to use both distributed data forwarding as well as the ability to forward wireless traffic across broadcast domain boundaries.

802.11n is a complex standard with interdependent pieces. Previous PHYs were able to come to market all in once piece, so that 802.11g did not exist, and then it did, fully formed. The complexity of 802.11n means that it has come to market in distinct “waves” or “phases.” Part of the reason for phases is that the difficulty in standardization is determining what the frame format should be, and what is eventually possible to build into hardware. However, the incremental work in adding 4-stream transmission to 802.11n is very small compared to the hardware engineering needed to put four radio chains in close proximity.

One way of thinking about the market is to think of it in technology waves, where a wave is a set of products that hit the market at about the same time. When building wireless LAN products, the most important component is the radio chipset, a set of silicon chips that implement the components shown in Figure 3-7. Typically, the amplifiers are put on a radio front-end card, which allows them to be customized to a particular application. Long-distance transmission or high rate-over-range can be achieved by using higher-quality radio front-ends. The radio chip itself will have a PHY section that demodulates data, possibly from several data streams, and corrects any errors by using the error-correcting code. The resulting bit stream is passed to the MAC where security is applied, any frame deaggregation is done, and so on. APs are built around radio chips, so the technology waves in APs are driven by new radio chipsets.

In 2006, the 802.11n market was tiny, and the draft 802.11n standard was only in its first draft.^[43] Several areas of the standard had different interpretations, and radio chipsets for 802.11n were maturing along with the draft standard itself. Many of the earliest chipsets only supported operation in 2.4 GHz, and the only way to guarantee interoperability was to buy products that used the same chipset vendor. In retrospect, I labeled the 2006 time frame as the zeroth wave because there wasn’t really a large market.

The first wave came a year later, with the second draft of 802.11n. After the 12,000 comments received against the first draft, the second draft was much expanded and refined. Due to the perception of non-interoperability, the Wi-Fi Alliance began certifying products against the developing standard, an action which helped focus the standards developers on working out the major contributors to interoperability. The draft 2.0 certification program cemented the major components of the developing standard in place, and created a market where interoperability was tested and became a major focus of product vendors. The first wave was when 5 GHz products came to market, as well as when 802.11n enterprise devices emerged, most of which used a 3x3 MIMO design that supported two spatial streams. Power consumption of these APs was quite high, and often exceeded the 802.3af power budget.

The second wave of products was driven by the ratification of the 802.11n standard in 2009. Customer feedback on the first wave of enterprise devices was that full functionality was required on the 802.3af power budget, and the industry responded. Second-generation 802.11n hardware from chipmakers were 2×2 MIMO designs supporting two spatial streams. Removing the third radio chain and using better chip manufacturing techniques meant that the second-generation of 802.11n enterprise devices operated at similar speeds for the end users, but with much lower power consumption.

The third wave of products in the enterprise came in 2011, as 3×3 MIMO designs supporting three spatial streams came to market. At the time this book was written, high-end APs were all three-stream designs. It is likely, though not definite, that most chip designers will focus their four-stream efforts on 802.11ac, the forthcoming gigabit standard.

The Wi-Fi Alliance is an industry association of companies that are driving wireless LAN technology. The Alliance is best known for the Wi-Fi CERTIFIED interoperability testing program that began in 2000. Prior to 802.11n, the underlying PHYs were simple enough that there was a single set of core capabilities and very few optional features. The statement that “this device supports 802.11a” meant the same thing for any 802.11a device. With 802.11n, however, the underlying technology is much more complex. 802.11n devices certified for interoperability by the Wi-Fi Alliance are given the designation Wi-Fi CERTIFIED n, and are required to meet a minimum set of 802.11n technology components.

Once certification is complete and a product is awarded certification, it can be looked up at the Wi-Fi Alliance certified product listing. Each product is also given an interoperability certificate that details the individual product features that have been certified. Figure 8-4 shows a sample interoperability certificate, in this case, for an Aerohive HiveAP 330. In the upper-left hand corner of the interoperability certificate, the Wi-Fi CERTIFIED logo shows the basic interoperability certification (in this case, 802.11a/b/g/n); these logos often appear on product literature and packaging. Below the certification logo, there is a box noting the number of spatial streams supported by the device (in this case, three). As a point of contrast, Figure 8-5 shows a certificate for a client device (in this case, for a Dell card used as a reference design). This card has support for the greenfield preamble and wide channels in the 2.4 GHz band, both of which are displayed in the left-hand column.

Figure 8-4. Wi-Fi certificate (for an AP)

Figure 8-5. Wi-Fi certificate (for a client)

If your 802.11n network is an upgrade from an existing 802.11a/b/g network, a good first step in getting maximum performance for a given cost is to reuse existing mounting locations. Cabling is often one of the major costs of building a wireless LAN, and reusing existing cabling is a good first step, especially if the cabling is in place to many of the locations where you would want to put wireless LAN coverage.

802.11n APs might show a small increase in speed by moving to a new mounting location, but the cost involved in resurveying and recabling new locations is almost always prohibitive. From a cost efficiency standpoint, it is cheapest to install 802.11n APs in the same locations as the existing 802.11a/b/g APs, and then add extra capacity where it is required. Typically, 802.11n offers the highest benefits in high-density/high-capacity locations such as auditoriums, conference rooms, and other areas where large numbers of users tend to gather. As demands on the network grow, additional capacity can be added as network usage increases.

When building a new 802.11n network, especially for coverage, it is best to design the network around the needs of 5 GHz coverage. Because radio range at 5 GHz is somewhat shorter, and the 5 GHz band bears the brunt of building a high-capacity network, it is best to lay out a new network with mounting locations selected to obtain desired 5 GHz coverage. Only once that is complete, enable radios on the 2.4 GHz band. Due to the longer reach at the lower-frequency band, only a subset of APs will need to have their 2.4 GHz radios active.

The easiest component of channel layout is the channel assignments. Just let your network pick channels itself. With rare exceptions, automatic channel selection algorithms converge on a good enough channel plan that the gain in speed from picking channels manually is quite low and not worth the time.^[44] The important inputs to channel selection algorithms are the available channels and the capacity of each channel. 802.11n offers two channel widths: a backwards-compatible 20 MHz channel that is identical to 802.11a/g, and a new 40 MHz wide channel that offers slightly more than double the speed.

Practically speaking, an extensive deployment of 40 MHz channels will need support for the worldwide harmonized radio band (channels 100 to 144 in Figure 3-3). Using these channels requires that the AP support Dynamic Frequency Selection (DFS). DFS capabilities are required by radio regulators in each individual country, and support is tested as part of the government certification process required to sell radio devices. Without DFS, wireless networks in Europe are restricted to four indoor 40 MHz channels and wireless networks in the U.S. are limited to six. A key enabling technology for DFS operation is the IEEE 802.11h amendment, which is tested by the Wi-Fi Alliance and appears on the interoperability certificate as shown in Figure 8-4.^[45]

DFS support enables outdoor operations in Europe, as well as adding five additional 40 MHz channels.

Although DFS operation improves the number of channels, it is not perfect. Spectrum is the lifeblood of wireless LANs, and many channels are available on the condition that wireless LAN operation is secondary to primary uses of the band. Operation on channels where another use takes priority, such as weather radar on channels 100 to 144, requires that APs monitor for higher-priority transmissions and switch channels to avoid causing interference. Getting DFS right is tricky because an AP must cede the channel to a higher-priority use, but if it is too sensitive the resulting channel changes will result in unwanted network disruption. The only remedy for a wireless network administrator is to carefully assess whether channels that require DFS are needed to meet the goals of the network and carefully monitor the network in operation to ensure that any channel changes are the result of actual interference and not merely false positives.

In addition to dynamic channel selection, many APs have the ability to automatically adjust transmit power through a function called Transmit Power Control (TPC). Transmit power adjustments are often described as a way to fill in coverage holes or otherwise help a network to “self-heal” in response to changes in the radio environment. TPC, however, can easily create asymmetric links, as shown in Figure 8-6. In Figure 8-6(a), the client device power is set much higher than the AP transmit power. Although the AP network has optimized itself for high coverage density with relatively low transmission power, a client device set for much higher transmission power may cause the carrier sense in a large surrounding area to read busy. Figure 8-6(b) shows the opposite problem, in which the AP transmit power is set very high and a low-power client is no longer able to reach the AP.

Figure 8-6. Transmit Power Control and link asymmetry

The key for network administrators in configuring TPC is to guard against both types of link asymmetry. Begin by determining the maximum transmit power of mobile devices, and capping the transmission power of each AP at the level of the typical client. Laptops typically transmit at a maximum power of 100 mW (20 dBm), but may be set lower to conserve battery power. Phones are often capable of the same power level, but higher transmit power does decrease battery life. A good compromise is to set the network for a maximum power of 30-50 mW (roughly 15-19 dBm).

In the early days of wireless LANs, just getting a packet capture could be a challenge. Thankfully, those days are behind us, and many software products exist to easily obtain a packet trace. For quick analysis, I use Wireshark because it is a cross-platform tool that is equally available on MacOS, Linux, and Windows, and my long history with tcpdump has resulted in the ability to write filter rules using the familiar Berkeley Packet Filter (BPF) syntax. Installation is straightforward, with ready-to-run code available easily.

When doing frame analysis, your analyzer will read frames from the wireless interface and display their contents. Critically, the frame is only available if it is received by your analyzer. With Ethernet, the analyzer can be plugged in, and barring extremely unusual problems or bugs in port mirroring code, will receive frames without issue. On a wireless network, the analyzer only receives what it can decode. To troubleshoot client problems, it is often necessary to physically take the analyzer to the problematic location and set it down next to the device. Ideally, your analyzer will use the same chipset as the client device so that it has similar performance characteristics, though that will not be necessary in most cases.

Some APs include a remote capture tool, which has the advantage of providing the stream of frames as received by the AP. Remote capture from the AP can be used to diagnose problems by looking at the data stream from the AP’s vantage point, perhaps while cross-referencing with an analyzer on the client side. For example, if a connectivity problem occurs, comparing captures from the AP and an analyzer near the client device may help you determine if frames are being lost in the air.

Wireshark has several capture modes. For wireless LAN usage, you will want to capture in monitor mode, which reports all received frames up the software stack. Monitor mode is required to capture 802.11 header information as well as radio information such as the data rate and Received Signal Strength Indication (RSSI).

The 802.11 MAC manages airtime, which means that performance tuning in 802.11n uses similar techniques to previous PHYs: reduce airtime contention when you can, and pack as many bits into each microsecond when that fails. Just as in 802.11a/b/g, reducing the coverage area of each AP works to increase the frequency reuse and provides independent channels. Just as in 802.11a/b/g, the spectrum in the 5 GHz channel is “cleaner,” with less interference, as well as the raw capacity from all the additional channels (see Channel Types and Layout). The past few years have seen greater appreciation of the role of 5 GHz channels in improving throughput. Physics plays a role here: 5 GHz radio waves travel a smaller distance, enabling better frequency re-use.

Many manufacturers select default settings that are generally good for data networking, and will deliver acceptable performance for web-based applications and email. In fact, for 802.11n APs, many APs include a feature that gives priority to high speed 802.11n frames because they move data much more quickly than the older 802.11a/b/g frames. When transmitting a 1500-byte Ethernet frame, 802.11n needs less than a third of the time to move the frame at 300 Mbps than 802.11a/g does at 54 Mbps. When you factor in aggregate frames, the time savings are even more pronounced. Preferential treatment for fast 802.11n frames has the apparent effect of speeding up the network for 802.11n users with only minimal impact to users of older devices.