A few weeks ago I was invited to attend a Silicon Valley event hosted by Meru Networks called SDN Connect Live as part of a panel of professionals discussing the future of SDN as it pertains to Wi-Fi. Each of us offered a point of view a bit different than the others with backgrounds ranging from hard-core Microsoft applications to enterprise route/switch ending with me in Wi-Fi. We had a great discussion at the closing of the event which you can view at the Tech Field Day SDN Connect Live event page (I’ve also embedded the playlist below). The other delegates profiles are available on the TFD event page too.
My Take on SDN+Wi-Fi
Meru had some big announcements to make along with several of their partners and some representation from the Open Networking Foundation, specifically that they have added an OpenFlow agent directly to their controllers. This is pretty big news in both the worlds of SDN and Wi-Fi. Marrying the two technologies together has been discussed many, many times but this is the first time (as far as I know) that we’re seeing a vendor do more than get behind the idea. Meru dove in head first and is prepared to deliver a market ready solution (their claims, which may or may not be true, not mine).
Now, SDN is an interesting, deep, and often misunderstood topic. I’m not ashamed to admit that I have barely scratched the surface of what the market has been promising and delivering for the past year or two (Wi-Fi is just too interesting for me to pull myself back to the boring wired-side of things). Keeping that in mind, I’m coming at this topic from my own point of view, a wireless engineer. I don’t have any practical Open* experience and I’m a bit behind on where the community, market, and general vision are headed. With that said, I’m not 100% sold on this whole thing… Do I hate the idea? No. Though I’m not in love with it either.
Now before you jump down my virtual throat in the comments, let me explain.
A Serious Case of Déjà Vu
The Wikipedia entry for software-defined networking starts off defining SDN as:
…an approach to computer networking that allows network administrators to manage network services through abstraction of lower level functionality.
Okay, great! That sounds like something everyone can get behind… but doesn’t this sound a bit familiar?
The article goes on further to say:
This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). The inventors and vendors of these systems claim that this simplifies networking.
Okay, now really… A separate control and data plane? Decoupling management and traffic? How will you ever get a wireless engineer on-board with that sort of crazy talk? I’ve said it before and I’ll say it again… Welcome to he party wired guys.
I may be speaking from the limited knowledge I mentioned above right now but just like when BYOD became the big buzzword on the block (which I’ve talked about before), SDN has stepped in as the solution to a problem, a method, an idea; and Wi-Fi has known about and been working to streamline this for ages.
The networking industry has been kicking and screaming at how to properly do this. Between figuring out which way method works best to who’s got the best special sauce; all they needed to do was invite a Wi-Fi engineer to the conversation. We have been doing this for over a decade, we’ve seen the growing pains, the scale issues, the pitfalls, and worked through it. We’ve got massively global networks with tens of thousands of access points, hundreds of controllers, and all of it brought in to a single management interface. Granted, there’s no single architecture that everyone has unanimously agreed on and the holy wars that go with any discussion about them are pretty impressive but in general each method has its own place in the market and they aren’t all that dissimilar from one another.
Interoperability: A Word that Doesn’t Exist in the Wi-Fi Dictionary
capable of being used or operated reciprocally
Ever try to connect vendor X’s access point to vendor Y’s controller? They all speak CAPWAP, don’t they? How about deploying a network and using the best access points on the market for each location and need? Having APs that excel at large client count in high density areas from one vendor, low client/high traffic locations served by another vendor, parking lot mesh by a third, etc. Shouldn’t be that difficult, right? Good luck with that… but why can’t you?
The IEEE 802.11 working group has proposed and ratified many specifications that allow us to create wireless networks. Like any networking technology, it has to be built on standards in order for clients to be able to move seamlessly from network to network without the need for changes in hardware or software. We’ve got the nearly-universally known 802.11 a, b, g, n, and ac which define many specifications like channels, data rates, and modulation types used for basic connectivity and communication. Then there’s the lesser known (outside of wireless engineering circles) but widely used 802.11i standard which brought us better security. Going even further we have 802.11r for fast, seamless roaming and 802.11k for radio management. The list goes on. And on. And on. There a amendments for all sorts of interesting technologies and optimizations.
The issue with wireless networking is that an IEEE amendment does not equal a Wi-Fi Alliance requirement. This means we have all manner of carefully developed, proposed, and ratified amendments crafted for making wireless LANs better, faster, stronger but not being adopted by vendors. What’s more, vendors are taking the technology and developing their own additions as competitive "secret sauce" in a constant game of one-upping one another. This isn’t necessarily a bad thing and wireless isn’t the only sector doing this but when the optional technologies get left by the wayside in favor of proprietary methods we end up where we are; with networks that not only don’t play nice and work together, it’s difficult to make them even co-exist.
The point I’m trying to make here is that vendors don’t play nice now and have no real incentive to do so. What magical change is going to happen in the Wi-Fi world that will suddenly change this?
That’s right, my last point is simply "Why?"
SDN’s home has been in switches and routers so let SDN stay in switches and routers. It’s not that I’m against it but why add complexity to already incredibly complex systems when you don’t need to? Why add extra overhead right as we’re adding our own stress to the processors with things like application visibility? I’m almost positive that no matter what sort of wireless network you’re deploying the traffic gets dumped from the access points to a switch. Whether or not it goes through a controller or not is inconsequential for this point. Let the switch do what it does and direct the traffic from there.
SDN + Wi-Fi as a First Step
Doing something interesting like coupling some technologies together never hurts. I love tinkering away in my office for the sake of tinkering. In fact, I’ve made some pretty useful tools by accident because of this. I’m positive there are plenty of times that tech gets reinvented or even born this way. "Experimentation is the new planning" as they say. Just because we can do it doesn’t always mean we should though, and in this case just because we can put SDN into controllers probably doesn’t mean it’s going to change the face of Wi-Fi. But it could be the start of something new…
The team over at Meru has taken a big chance, a huge leap of faith, here and I applaud them for that. I hope they can parlay this bold move and push the industry towards more than just SDN; I’m talking complete interoperability. This is Wi-Fi’s real first steps into those uncharted waters which may turn out to be a dead-end or the giant leap needed to take the technology to the next level. As I said, I’m not sold but I’m definitely watching and listening to see what happens next.