What is a WLAN controller (part 1)
According to the Oxford Dictionary, a “Controller” is defined as:
Therefore, a wireless LAN controller is a device that directs or regulates traffic on the wireless network and is sold by WLAN controller vendors.
So why does this device exist on WLAN networks and not in a switch or router environment?
Well, let’s take a step back for a second and figure out how we got here. If we travel alllll the way back to early 2000s, wireless LANs were just emerging in the enterprise. In fact, most people still worked on desktop computers and laptops were just starting to become the company-issued device of choice.
As they did, people wanted to be able to use their fancy 802.11b wireless NICs to connect to Wi-Fi when they were away from their desks, such as during a meeting in a conference room. Lots of enterprises started deploying access points (APs) during this time, and their choices all were relatively similar, regardless of whether it was consumer-grade or enterprise-class: autonomous, basic authentication (if any), manually configured channels and power settings, and generally little in the way of centralized management. This could quickly become a management burden in larger facilities for coordinating RF and user access.
Fast forward a couple years to the arrival of Airespace. Airespace came out of the gate and won every new tech award on the block because they found a way to do something so many IT administrators were then struggling with - make the wireless network work more like the wired network by providing a centrally controlled and managed WLAN for the enterprise. All of a sudden, admins could go to a single place to manage RF, authentication, QoS, and even advanced functions like location tracking and intrusion detection. Airespace called this innovative product something everyone could easily relate to: A wireless LAN Switch.
This Wireless LAN switch provided the necessary CPU and memory to calculate complex channel plans, centralize authentication and offload encryption, and ensured that IT admins, even one who was responsible only for the wireless and not the wired infrastructure, could manage the Wi-Fi network by tunneling everything back to the switch.
Fast forward again, and Airespace does so well that Cisco acquires them and starts adding to their line of existing autonomous APs. The only problem was, by this point, there were competitors, and Symbol had a wireless LAN switch too. In typical Cisco fashion, they quickly EOL’d the existing Airespace products and replaced them with a newly named product that defined the next decade of Wi-FI: The Cisco Wireless LAN Controller.
In 2005, a wireless LAN controller made sense because it centrally managed, configured, and provided the necessary controls for a wireless LAN deployment. Even by 2006, though, there were doubts that this was the path forward. Already companies were starting to talk about 802.11n, and surpassing 100Mbps per client.
How big could the backplane really get? How many access points can a single controller control if the clients keep getting faster?
As the price of CPU power and memory decreased, we saw the birth of Aerohive, and our mission to regain control of the wireless LAN without a single point of failure or bottlenecks. In the years since Aerohive launched its first product in 2007, we’ve fought for mindshare that controllers should not be the future for large-scale deployments and that real-time decisions and control can be distributed at the edge.
Of course, centralized management is still a key component of any enterprise deployment, but a network management system should not be part of the data or control plane functionality. And in the past couple years, *especially* with the availability of gigabit Wi-Fi and the prevalence of application visibility and control, we are finally getting there. Companies like Aruba have bifurcated their product lines to add controller-less options. Cisco made one of its largest acquisitions in a decade by purchasing controller-in-the-cloud vendor Meraki. And slowly we are seeing more competitors acknowledge that controllers are not the best means to scale in a mobile-first world.
Then why do they still exist? What do they still do?
Even before companies were figuring out a cooperative option, they were already taking away “control” from the controllers. In this day and age, it’s not common to have a wireless LAN vendor tunnel ALL data back to the controller. Why? Because it cannot easily scale given the number of clients and speed of those devices. Most of them still have some dependence on that legacy appliance, whether for auth, or roaming, or deep packet inspection, but rarely are the WLAN controllers providing an overlay network to tunnel all traffic back to a centralized place.
In fact, many vendors will tell you that they can distribute radio management functionality, or WIPS, or feature xyz out to the APs. So then the question becomes - why are there still controllers? If they can distribute the control, and they don’t *need* them, why are they still there? If they just want centralized management, it would be called an NMS.
Why continue to sell these devices? Likely because our competitors may rely on controller sales for a significant amount of their quarterly revenue. Take a look at the 2014 Infonetics 4Q13 Wireless LAN Equipment and WiFi Phones Analysis Report for more details.
What we’re really seeing isn’t a fundamental disagreement in architecture or technology. In fact, we could argue that most of the competitors are onboard with the claim that distributed control is the way forward. What they haven’t figured out yet, and the reason they still sell those devices, is that they make a lot of money. And as we’ve heard from folks with lots of money on Shark Tank, “Follow the Green, not the Dream”.
So - the question is, which product are you buying? The green or the dream?
Have a comment? There's a WLAN controller conversation happening on our community.
To read the follow on to this blog - What is a WLAN controller (part 2) visit here.