Is SDAs large-scale carrier Wi-Fi deployment accelerates, the all-important question of how these networks will be managed is gaining centre-stage. Is Software Defined Networking on the cards?
Operational challenges for Service Provider Wi-Fi
The management of Enterprise Wireless LANs has always been fraught with complexity – requiring site-surveys and planning before physical Access Point installation and final provisioning of services to access points. In the world of carrier Wi-Fi, these human-intensive practices will not fly. Physical deployment and configuration needs to be dramatically simplified and service provisioning needs to scale to an order of magnitude that is inconceivable in Enterprises.
Three things are needed. The first is zero-touch auto-configuration regardless whether an AP is in someone’s home, a retail outlet, enterprise or large public venue. The second requirement is cloud-based provisioning of services and features on a massive scale. And the third is cloud-based performance management and user/usage analytics.
Moving Wi-Fi control to the cloud is just a start
Over the coming years, service providers will need to upgrade features and services on access points over and over again, in order to enable ever-improving capabilities for Wi-Fi offload, seamless roaming, social Wi-Fi and OTT services, not to mention needing to reconfigure devices dynamically to avoid interference from neighboring APs or other interference sources they have no control over.
The recent trend of Enterprise WLAN vendors to move controllers to the cloud goes a long way to toward simplifying initial deployment. Nowadays, many APs are designed to be plug-and-play and to auto-discover a controller in the cloud. But few vendors have scratched the surface of enabling large-scale provisioning from a service provider’s OSS. Existing controller architectures are mostly hardware dependent, and pricey. Plus they do not scale to anything near the level necessary for Carrier Wi-Fi. Another step to fully virtualized control is needed. But even when they do that, all major vendors suffer from a major drawback – their WLAN control protocols are highly proprietary.
Service providers have several short term and long term challenges concerning Wi-Fi deployment and they are all bounded by tremendous pressure to push down access point CAPEX and minimize OPEX. One of these challenges is to avoid vendor lock-in, and to this end, they are interested in solutions that will enable them to provision and manage a minimum feature set on a heterogeneous access layer.
As Wi-Fi and mobile converge service providers also recognize that that heterogeneous access layer may not comprise only Wi-Fi access points, but also 4G/LTE small cells, even Ethernet switches and EMTAs. Proprietary WLAN control does not fit well in this picture.
The vision of Software Defined Networking (SDN)
This is precisely why service providers are looking to Software Defined Networking (SDN). While still in its infancy, SDN promises to give service providers a uniform control plane for managing heterogeneous access networks, unifying policy management across wired and wireless networks of all types. However, as far as wireless LANs are concerned many questions remain about the right protocols to employ, and whether or not the WLAN vendors, who historically have very closed systems, will ever play ball.
In conventional networking, routers and switches handle both high-level routing (the control path) and packet forwarding (the data path). The idea of SDN is to decouple control-plane and data-plane, by storing control-plane information in a centralized controller. The controller then uses protocols to communicate with network components and provision the services and policies that should exist on that component. In theory, with software-based SDN controllers virtualized in the cloud, the network infrastructure itself can be made up of dumber, less expensive devices from any vendor.
This centralized control model, potentially allows rapid reconfiguration of services across the network, without ever needing to configure individual edge devices. In a sense the network becomes like one big switch, in which VLANs, Subnets, QoS profiles and ACLs can be changed simultaneously across multiple components as a result of say a new server coming online, or perhaps a Wi-Fi user roaming from one access point to another, where previously there was no instance of that users’ VLAN.
Illustrating the power of SDN with Wi-Fi roaming
Wi-Fi roaming is a useful example to illustrate some of the benefits of SDN. For one thing, today, Wi-Fi roaming is client driven. Clients decide for themselves when and where to roam, and every time they do, they suffer a small delay, which is easy to see when streaming HD video. Roaming in a SDN controlled network could make roaming a network driven event, as it is in cellular networks, with the benefit of faster roams, and more prudent choices. For example choosing the least loaded AP, over the one with best signal. Further, the roam could occur seamlessly even between an AP from one manufacturer, and another, which is not possible today, without authenticating from scratch on the new network – that’s seconds, not just milliseconds of interruption. Clients could potentially have more than one active data connection – a form of connection bonding, similar to DSL bonding techniques.
Take this network controlled roaming concept one step further, and you can see how it would be possible to roam voice sessions, without interruption from LTE to Wi-Fi. And this is clearly an attractive proposition to mobile operators that have access to a Wi-Fi roaming footprint.
What is the protocol of choice for SDN?
In theory, any one of a number of protocols could be used to accomplish this, and there are several contenders. Although CAPWAP is one alternative, the one getting all the limelight today is OpenFlow. Openflow started out as a research project in Stanford in 2008, and is now being rolled out in select applications especially data centers. But its application could easily extend to Wireless LANs. While all this makes a lot of sense for equipment buyers, it undermines the account control vendors have over their customers. So vendors have a justifiable resistance to Openflow compliance, and are cautious about making their equipment Openflow-friendly.
We’ve seen this movie before. Roll back the clock to 2006 and you’ll recall that enterprise Wi-Fi vendors were bullish about embracing RFC-compliant CAPWAP and the multi-vendor interoperability it would allow. But CAPWAP has so many optional features, that within a few short years each vendor’s CAPWAP implementation had morphed beyond all recognition, partly to accommodate their unique bells and whistles. Could the same happen to Openflow? Or will we see the WLAN vendors open up to Openflow this time around?
Both Meru and HP have made bold commitments to supporting OpenFlow across their respective product lines. In HP’s case it is across both wired and wireless. But there’s open and open! Meru’s approach, which is to add an OpenFlow shim on top of its own controller, does nothing to eliminate costs in the whole system. Yes, it provides unified management, and this may be interesting to Enterprises, but it’s not a big enough leap for service providers. They want their SDN controllers to be able to provision access points or other CPE devices directly, not through an expensive intermediate hardware platform.
What other Enterprise WLAN vendors choose to do, may be little more than the “SDN-washing” just described. They are too frightened of losing account control, and the high margins this affords them. Let’s face it, nowadays, it is quite hard for incumbent vendors to lose a mature account, because the customer pain of switching vendors, or even having a dual vendor strategy is so high. WLAN vendors would prefer to keep it that way, for as long as possible.
What is really implemented in Carrier Wi-Fi networks?
Before we get too enamored with Openflow, I said earlier that there are alternative protocols that could underpin SDN. CAPWAP is one of them. CAPWAP and Openflow are essentially the same thing. They were both designed as an open control protocol between a controller and a set of network devices. The main difference is that CAPWAP was limited in scope to wireless Access Points, but it doesn’t need to be.
While Meru, HP, and a handful of few newer entrants to the Cloud Wi-Fi market have announced intentions to use OpenFlow (e.g. Tallac), CAPWAP is by no means dead and buried. Other WLAN vendors (e.g. AeroHive) prefer CAPWAP for their Cloud offering, as do some new pure-play Cloud Wi-Fi entrants (e.g. Relay2). Fortinet also uses standards-based CAPWAP as part of their solution for offering unified security across wired and wireless platforms.
CAPWAP may not be getting much press these days, but there is no doubt it is alive and flying low under the radar. The fact is it works today. It is proven and scalable. Many carriers deploying a large-scale Wi-Fi network today have little choice – Either, build your own solution based on OpenFlow (untested at scale), or go with a proprietary single-vendor solution (overpriced), or deploy CAPWAP (already proven, in large-scale deployments). Deutche Telecom seems to be sponsoring both camps, on the one-hand researching OpenFlow, on the other, recently filing a patent application (Feb 2014) for a Virtual AP which is an extension of the split MAC model defined in the CAPWAP.
By far the more economical and lowest risk choice today, is the CAPWAP option. In terms of RFC-compliant CAPWAP stacks and solutions, a slew of vendors in China and Taiwan are already building CAPWAP based controllers. Autelan, H3C, Ruije and several other players have already implemented CAPWAP and extensions for carriers providing an open environment which can be customized based on carrier requirements. Ericsson’s Carrier-Grade Wi-Fi controller (WIC8000) also uses CAPWAP to manage and provision APs. Even the Chip vendors have begun looking at CAPWAP to better enable carrier opportunities. The existing CAPWAP controllers are a mix of hardware-based and software only solutions. They should all be able to interoperate with a mix of low-cost access points from a wide range of ODMs.
Carriers in Asia have cast their vote. CAPWAP is the protocol of choice. Several mobile and wireline carriers are in the midst of rolling out some of the worlds’ largest multi-vendor Carrier Wi-Fi networks based on CAPWAP.