Don't Let Wireless Fall Off the SDN Bandwagon

Bjorn Smedman, CEO, Anyfi Networks
579
960
179

Bjorn Smedman, CEO, Anyfi Networks

Software-Defined Networking (SDN) is all the rage in the WLAN world and vendor after vendor is jumping on the bandwagon. But is the transformation more than skin deep?

SDN is about separating the control plane from the data plane, logically centralizing control while keeping packet forwarding distributed. As simple as it sounds it could be the most transformative concept to hit networking in decades. But its usefulness hinges on finding the right reusable abstractions to allow the control plane to be programmed.

Sadly the search for those abstractions doesn't seem to be going too well. WLAN vendors are adding SDN as a tick-box feature slapped on at the last moment; all the abstractions borrowed from the wired world; as if there was nothing below Ethernet. I think this could be, as Julia Roberts puts it in Pretty Woman, a huge mistake. Huge.

So what's so different about wireless and why can't it be programmed with the same abstractions as wired networks? To start with IEEE 802.11, unlike IEEE 802.3 (Ethernet), is not symmetric: access points and mobile devices have distinct roles, they're not just interchangeable senders and receivers. Also, Wi-Fi has network selection, authentication and encryption built into the MAC layer. And then there's rate selection and a myriad of QoS mechanisms. All in all the IEEE 802.11-2012 standard is 2695 pages(!), nearly all of them about what happens below the Ethernet level.

The key principle behind SDN is separation of concern; essentially the idea that problems are easier to deal with when divided into sub-problems of manageable size. In wireless there are two quite different sub-problems hiding in plain sight: radio access and service definition. The former entails the question of how to deliver bits to and from a mobile device over an air interface. Service definition on the other hand is everything else: network name (SSID), authentication, encryption, address assignment and of course all the higher level packet processing and forwarding (OSI Layers 3-7) are all aspects of the logical service. To me it seems natural that radio access and service definition should be separated, and that radio and service should be the two most fundamental abstractions of a programmable wireless control plane. Let me tell you why.

First of all, anybody who has configured a WLAN controller knows that the conceptual building blocks are access points (which contain radios) and SSIDs. The latter is an abbreviation of service set identifier, so an identifier for the service set, or service plain and simple. Since these are the abstractions we use today, when manually pointing and clicking us through our WLAN configurations, it's only natural that they should be the fundamental abstractions of tomorrow's wireless SDN control programs that will accomplish essentially the same task: controlling which services ("SSIDs") should be available to a mobile device from which access pointradios.

Clearly separating radio access from service definition will also make it much easier to reason about network security. Today's WLAN systems typically use digital certificates to authenticate access points to their controller, preventing a rogue access point from joining the managed WLAN. But this is just security by obscurity; whoever can connect a rogue access point to your physical infrastructure can also extract the digital certificate from a trusted access point - or simply run their malicious software directly on the trusted access point itself. On the other hand, if the Wi-Fi encryption is moved (along with the rest of service definition) to a virtual machine running on trusted hardware in a physically protected location, then the access point is completely out of the security equation. One thing less to worry about.

Then there are all the practical advantages of separating radio access from service definition. In an increasingly mobile world we more and more often find ourselves in one location and the networks we need to access in another. Today we typically connect to the closest Wi-Fi network, only to then connect onward with a VPN or some other remote access solution. Wouldn't it be easier if we could just connect to the wireless networkwe need to access, automatically? If radio access is clearly separated from service definition, and an SDN control program can connect any radio to any service through a Wi-Fi over IP tunnel, then we could simply just let our devices connect and authenticate using the same credentials we use every day to connect in the office. The mutual authentication and encryption built into the IEEE 802.11 protocol would protect your data end-to-end. It's as strong as any VPN.

Must-have corporate WLAN features like guest access, bring your own device (BYOD) solutions and remote access points fit beautifully into this framework. Are employees bringing more and more devices into the workplace demanding to have them connected to Wi-Fi? Just have your SDN control program connect them - to their own home Wi-Fi! Do you have consultants that need to connect to their own corporate networks? Just have an SDN control program connect your radios to the consultancy company's service. You've minimized access to your sensitive information, and your consultancy partners feel safe knowing that you can't eavesdrop on or modify their day-to-day communication.

But all this hinges on us as an industry finding the right abstractions for wireless SDN. Let's not leave tomorrow's network engineers with the impossible task of program­ming wireless networks with wired abstrac­tions. Let's not let wireless fall of the SDN bandwagon.

Björn Smedman

Read Also

Creating a Sustainable Innovation Program

Armin Roeseler, CIO, DirectBuy

To The Cloud & Beyond-A Death Knell for Private Data Centers?

Toney Flack, CIO, Wichita State University

Building a Network for the Unknown

Fredrik Lindstrom, Manager CIO Advisory, KPMG

Creating an Innovative Environment

Kurt Madden, CTO, Fresno Unified School District