Split MAC Architecture

Okay—yes. It sounds weird, but this odd-sounding name is actually a pretty cool feature. We’re basically splitting the processing of the 802.11 protocol between two devices, the AP and a centralized Cisco WLAN controller. Figure 1 shows how the “splitting” of processing occurs at each location.

Figure 1: Split-MAC Architecture

Although the 1520 AP and the 1020 AP appear to be directly connected to the controller in Figure 1, they can’t be—first, because they’ve go to connect with a switch to provide 10/100 to gigabit conversion, and second, because the controller only forwards LWAPP packets coming from an LWAPP-enabled port. This means you need a router if you want to take an LWAPP packet and forward it out as IP data to a non-LWAPP network. A high-end switch can handle the routing.

The AP handles the portions of the protocol that have real-time requirements:

1.The frame exchange handshake between a client and AP when transferring a frame over the air 2.Transmitting beacon frames
3.Buffering and transmitting frames for clients in power save operations
4.Responding to probe request frames from clients
5.Forwarding notification of received probe requests to the controller
6.Providing real-time signal quality information to the controller with every received frame 7.Monitoring each of the radio channels for noise, interference, and other WLANs
8.Monitoring for the presence of other APs
9.Encryption and decryption except in the case of VPN/IPSec clients

All remaining functionality is handled in the Cisco WLAN controller, so time sensitivity isn’t a concern but controller-wide visibility is certainly required. The following are some of the MAC-layer functions provided in the WLAN controller:

1.802.11 authentication
2.802.11 association and reassociation (mobility)
3.802.11 frame translation and bridging

And if a Cisco Wireless Controller in Appliance mode fails, its dropped Cisco APs will poll the network for another Cisco Wireless Controller. When an online Cisco Wireless Controller has any remaining AP ports, the management interface listens to the network for Cisco AP polling messages to auto-discover, associate, and communicate with as many Cisco APs as it can.

Note:Basically, the split-MAC architecture allows the splitting of 802.11 protocol packets between the Cisco LWAPP-based AP that handles real-time portions of the protocol and the WLAN controller that handles any items that are not time sensitive.

Cisco’s Unified Wireless Solution

With a range of products that support IEEE 802.11a/b/g and soon “n” technologies, Cisco really does offer a pretty complete and impressive line of in-building and outdoor wireless LAN solutions. These products include access points, wireless controllers, wireless LAN client adapters, security and management servers, wireless management devices, wireless integrated switches and routers—even antennas and accessories. Did I say impressive or what?

Since about the year 2000, a lot of corporations have relied upon basic access points as their main wireless networks and connected them into an infrastructure, which allowed users to roam within their network. Figure 1 shows a typical infrastructure network, either with one access point or as an extended service set wherein you would have multiple access points — all using the same Service Set Identifier (SSID) for roaming purposes.

Figure 1: Typical infrastructure network

So what we see here is that each of the APs, in either configuration, is configured as a root AP. If you were to look back in Chapter 4 at the configuration of my two wireless routers (R2 and 871W) and the 1242AP, all three were configured as roots. Basically, this means that each router is essentially saying, “Yo, wireless client, connect to me and get your goods (wired resources).” If the APs weren’t root, they could only connect to a root device as a repeater. Nonroot devices include clients, bridges, repeater access points, and work group bridges. 

But wait a minute—that was like the IT Cretaceous period or something. Definitely not now when it’s almost 2008 and we have on the horizon the Cisco Unified Wireless Solution that provides a comprehensive, integrated WLAN solution! This new, tricked-out technology includes intelligent Cisco APs and Cisco WLAN controllers specifically designed to support APs. The solution is managed either through the controller web interface, from the controller itself, or from Cisco’s Wireless Control System (WCS).

But the really sweet thing about this type of network is that after initial installation, it requires zero configuration. This means that you can connect an AP in an outdoor or indoor environment and the AP will automatically configure itself based on the controller’s information. It will even check for channel overlap and interference and assign itself a non-overlapping channel—how cool is that? And as I briefly mentioned earlier, if it happens to detect an overlapping channel within its area, it’ll lower its transmitting level to limit interference. Cisco calls this “auto RF controls.”

The news isn’t all sunshine—this product line isn’t necessarily for the poor because it can require that you to get your hands on quite a stash of goods. Yep—you’ll need more than just an AP for sure. Your minimum shopping list is a Cisco 1020 AP and a controller for an indoor solution, and for outdoors, a Cisco 1520 AP and a controller. And remember, these are minimum requirements. Reality will probably require more stuff—I use both the 1020 and 1520 APs in my classes, and I’m using them to write my book along with two types of controllers—the absolute minimum number of devices I can use to still make this functional. The APs are reasonably priced, and as is usual for Cisco, their cost pretty much follows the product model number. It’s the controllers that’ll make your coinage disappear—they cost thousands! Hopefully, by the time you read this book, they’ll have come down in price to somewhere below the stratosphere. There’s always hope! 

But for fun, let’s pretend you have a decent sized network with unlimited funds to spend on it. First, get a hold of at least two controllers (the good ones run about $20,000 a piece.) Why two? Because every packet from every AP must go to the controller in order to then be placed either on the wired network or back out to the wireless network. The controller decides the packet’s destiny based on the Lightweight Access Point Protocol (LWAPP) information that’s encapsulated on it. (I’ll tell you more about LWAPP in a minute.) Anyway, the reason you need at least two of these beauties is in the unfortunate event that one of them goes down. You’d be full-on nuts to create a design that has only a single point of failure, so, being completely sane, you’ll get two and create the redundancy you’ll need for this type of network. 

Okay, now that you’ve got the single point of failure thing covered, you need to be able to manage your controllers as well. Cisco has the GUI Wireless Control System (WCS) to manage the entire WLAN from a single interface that also happens to provide you with some seriously detailed insight into the network coverage, the trending of network statistics, and the details on device location. (Remember—money is no object!)

The thing is, you really don’t need to have the WCS because the Cisco WLAN controller analyzes the data collected by the APs, which can be managed either at the individual controller or by the comprehensive tools within WCS. But since you’re rolling in it, you are definitely going to hook yourself up with that WCS.