To date, the SDN discussion has been largely focused on the data center and wired networks. As enterprises move to virtualization and the cloud, they see that the configuration of conventional networks are time-consuming and error-prone. A virtual server might be created in minutes, but changing the underlying network infrastructure might take days or weeks. SDN has emerged to solve this problem for data center and wired networks the way virtualization did for servers. With the explosion of mobile devices and the emergence of 802.11ac with gigabit speeds, wireless however has become the preferred method of access to the network. Smartphones, tablets and laptops are just the beginning. Billions of other devices or the Internet of Things (IoT) will be connected wirelessly in the upcoming years. Gartner estimates that 26 billion devices will be connected to the Internet of Things by 2020.

WLANs are no stranger to the concept of decoupling or separating the control plane from the data plane. This serves as the foundation of many cloud-based WLAN offerings today. For example in October of 2009 prior to Software-defined Networking (SDN) being a trendy topic and popular buzzword in the industry, the company I worked for at the time (Bluesocket), released its innovative virtual Wireless LAN (vWLAN) architecture. Unlike traditional controller-based WLAN architectures where the management, control and data planes all reside on a centralized hardware-based controller, vWLAN introduced the concept of separating the management and control plane from the data plane and implementing the management and control plane in software. While a proprietary Southbound Application Programmatic Interface (API) allows the vWLAN to define the behavior of the access points, a Northbound RESTful Web Services API presents a network abstraction interface to applications and management systems. These are fundamental components of an SDN, in fact ADTRAN’s Bluesocket vWLAN might be considered the industry’s first SDN for WLANs (albeit with a proprietary Southbound API). Although WLANs are no stranger to several concepts of an SDN, they typically still represent a separate network, separate controller, separate management tools and a separate set of policies. The user experience can differ from wired to wireless. For example the authentication method might differ and application performance could vary. The discussion must move towards open southbound APIs down to the APs and unified wired/wireless Software-defined Networks.

Some of the benefits enterprises can achieve through unified wired/wireless Software-defined Networks in the near future include: Centralized, unified wired/wireless management and control. A programmatic, single pane of glass across multi-vendor wired/wireless networks. For example a voice application could automatically apply QOS settings across the wired/wireless network; Unified wired/wireless policy enforcement and network access control. For example guests that connect to the wireless network would get the same user experience as guests that connect to wired ports in the conference room including authentication methods, captive portals, QOS, bandwidth allocation, layer 2-7 firewall rules, location and time based policies; Unified wired/wireless device and application visibility. For example enforce policies for a certain device type with a certain application consistently across wired/wireless.

In conclusion. To date the SDN discussion has been largely focused on the data center and wired networks. Some WLAN solutions already embrace several concepts of SDN. For those WLAN solutions that already embrace several concepts of SDN, the discussion must move towards open Southbound APIs, APIs down to the APs, and unified wired/wireless networks and the benefits that can be had.

Need more background info on SDN? Go back to Part 1.