Evolution Of The WLAN Controller

I’ve never hidden my love for wireless networking. There’s something so magical for me about the physics of radio waves. Even though I’ve never been in a role where it’s my primary responsibility, I somehow manage to socially engineer my way onto wireless projects. So I’m a Wi-Fi nerd in stealth mode, with two test enterprise networks at home, convincing everyone that I have this setup for security testing.

To be honest, though, it's more of a love-hate relationship. While I love the functionality and ease-of-use wireless offers a user community, the security and management concerns often send me into an anxiety attack. The arrival of the wireless controller helped assuage my fears by delivering valid methods of mitigating risk, but this higher level of security often comes with increased complexity and degraded performance. Today, WLAN architecture has evolved as the benefits of a controller-based network overlap with non-controller systems.

Before examining the evolution, let's review some basics. In networking, you’ll often hear about three planes of operation: management, control and data. Essentially, this trifecta describes the key functionality of networking devices. To oversimplify, management is what network engineers do on a daily basis, including configuration and administration. The control plane includes the exchange of routing information between devices, while the data plane consists of forwarding user traffic.

In the beginning, there was the autonomous WLAN architecture. Early access points (AP) were independently configured bridges providing access to the Ethernet network. However, as popularity of wireless grew, so did the need for a single point of management, enhanced security and seamless roaming to support device mobility. An early solution for dealing with these issues came via the wireless network management system (WNMS), which moved the management plane to a separate device, by centralizing configuration and monitoring.

Next came the centralized WLAN model. In this design, all three planes of traffic -- management, data and control --are often concentrated in a single device: the “controller. ” Network controllers have recently become a hot topic in Ethernet networking due to the recent advent of software-defined networking (SDN) and although the implementation differs somewhat, you can think of the centralized WLAN controller as proto-SDN.

With a centralized architecture, it became possible to facilitate user roaming between APs, deploy security profiles to devices and traffic, utilize rate-limiting and quality of service (QoS), and even segregate access. However, while the centralized model delivered improvements to traffic control, security and management in the enterprise, it also introduced chokepoints or concentrated points of failure. There’s nothing like having your wireless controller fail, especially when it’s configured for high availability.

And what about remote offices? If users wanted wireless, you’d either have to tunnel the traffic back to a centrally located controller, place one in an office with a handful of staff or (shudder) revert to the autonomous model. If you’re a global company with compliance requirements such as PCI-DSS, this quickly becomes a nightmare if you don’t have ready access to a network engineer in the location where you need to deploy the system. The telecommuting trend introduced additional security and management challenges.

[Read how Houston Methodist Hospital IT team maintains strict security and performs troubleshooting on the hospital's massive Wi-Fi network in "WLAN Management: How A Hospital Tackles The Complexity."]

With the explosion of mobile devices in the enterprise, the incidental nature of wireless turned into a mission-critical requirement, seemingly overnight. The new wireless demands came with problems that couldn't always be solved with the current WLAN technology., So WLAN architecture morphed into a distributed model, with controllers following suit, by either disappearing completely or converting into hybrid devices that included more flexibility in handling user traffic.

Now there are wireless devices from Cisco and Aruba specifically targeting remote workers, which keep the data-forwarding plane at the edge. There are also companies that offer cloud-based WNMS, such as Aerohive and Airtight, with highly intelligent APs behaving more like traditional network devices, seemingly unifying the best of both worlds without utilizing a centralized design.

There is value to both the controller-based centralized WLAN and the controller-less design model, depending on your needs. For example, in a campus environment, the centralized controller might be preferred. From a security standpoint, the ability to directly examine and manipulate the traffic by sending it through a controller can offer benefits if you need central visibility, correlation and integration for incident response with the wired network.

There also are questions regarding physical security of the uplink port required for the distributed model. On a university campus, you can’t always guarantee that the device won’t be unplugged and the port used for a malicious purpose.

However, a controller-less system has a definite cost-saving benefit. There’s no extra hardware to buy as you scale, because there’s no limitation based upon the ratio of APs to controller. Without a single point of failure or chokepoint due to a controller, facilitating remote access is as trivial as sending a single, pre-configured device to a user or remote office. The application of user access policies can also be easier to deploy in a global organization with fewer resources dedicated to provisioning and controller management.

Meanwhile, vendors in the space wage battles over the benefits of each architectural design, proclaiming the superiority of their technology over that of their adversaries. The only certainty in technology is change and as new requirements continue to emerge, it’s a safer bet to understand the benefits of each model and apply the technology where appropriate.