jump to navigation

Cooperative Control: Part 2 February 22, 2010

Posted by Devin Akin in : Uncategorized , 1 comment so far

Centralized Management, Distributed Control, and Distributed Forwarding

In order to better appreciate the Aerohive Networks cooperative control architecture, it is important to understand the three major functional areas, or logical network planes, that can be used to describe how network architecture operates: the management plane, the control plane, and the data plane.

By comparing the logical network planes of the most common networking devices – such as routers and switches – with that of HiveAPs, you can see striking similarities.

For example:

This architecture has proven to be the winning architecture for switched and routed networks for many years because it is scalable, high performance, and resilient while still allowing for central management.  As an example, the Internet uses this architecture.

Many enterprise WLANs today are implemented with a centralized controller-based architecture that breaks from this proven network architecture by centralizing the control plane and data plane in a controller hardware platform, which compromises scalability and resilience.

Aerohive’s cooperative control architecture is the first architecture to bring these proven network benefits to WLANs.  The following chart shows the architectural parallels between cooperative control and the proven architecture used in switched and routed networks.

Chart

Extending the proven architecture used in switched and routed infrastructures to WLANs through the use of distributed control and data planes is especially important as enterprises require greater levels of availability, increased performance with 802.11n, and seek to improve productivity in their regional and branch offices. Distributing the control and data planes (e.g., removing controllers) eliminates single points of failure and performance bottlenecks from the entire wireless network, allowing the remote site deployment to be as simple and as functional as the campus deployment.

Key Concepts and Naming Conventions

The diagram below shows that HiveAPs have different roles which are automatically designated based on how they are connected to the network. The following is a list of key terms used to describe the Aerohive Networks cooperative control architecture:

Diagram2

Diagram 2. Aerohive Networks Naming Conventions

Cooperative Control: Part 1 February 15, 2010

Posted by Devin Akin in : Uncategorized , 2comments

Introduction

The first generation of WLANs were autonomous (standalone) access points and were relatively simple to deploy, but they lacked the manageability, mobility, and security features that enterprises required, even for convenience networks.  Then centralized, controller-based architectures emerged to address these issues and others such as fast/secure roaming for mobile devices, radio resource management (RRM), and per-user or per-device security policies.  Unfortunately, they also introduced opaque overlay networks, performance bottlenecks, single points of failure, increased latency, and substantially higher costs to enterprise networks.  As Wi-Fi is increasingly embraced as a critical part of the enterprise network and enterprises deploy demanding applications (e.g. voice and video) over an extremely high-speed Wi-Fi infrastructure, the consequences of this movement are magnified and are leading the industry to reexamine the validity of today’s centralized WLAN architecture.

Aerohive Networks has responded by pioneering a new WLAN architecture called the Cooperative Control architecture.  It is a controller-less architecture that eliminates the downsides of controllers while providing the management, mobility, scalability, resiliency, and security that enterprises require in their wireless infrastructure.

Cooperative Control® Architecture

Aerohive Networks has developed an innovative new class of wireless infrastructure equipment called a Cooperative Control Access Point (CC-AP).  A CC-AP combines an enterprise-class access point with a suite of cooperative control protocols and functions to provide all of the benefits of a controller-based WLAN solution, but without requiring a controller or an overlay network.  Aerohive Networks’ implementation of a CC-AP is called a HiveAP.  This cooperative control functionality enables multiple HiveAPs to be organized into groups, called “Hives,” that share control information between HiveAPs and enable functions like fast/secure layer 2/3 roaming, coordinated radio channel and power management, security, quality-of-service (QoS), and native mesh networking.  This information sharing capability enables a next generation WLAN architecture – the cooperative control architecture – that provides all of the benefits of a controller-based architecture, but is easier to deploy and expand, lower cost, more reliable, more scalable, more ubiquitously deployable, higher performing, and more suitable for demanding applications such as voice and video than controller-based architectures.

The diagram that follows outlines the building blocks of the cooperative control architecture.  It is implemented using two types of products.

The architecture is supported by three distinct, but tightly-interrelated technology building blocks:

Diagram1

Diagram 1. Building Blocks of
Cooperative Control Architecture

Test, Test, and Retest February 8, 2010

Posted by Devin Akin in : Uncategorized , 5comments

Test and Retest were in a boat.  Test jumped out.  Who was left?

If you want “Wi-Fi that works”, you gotta test, test, and retest.  Silicon Valley is full of some wicked smart software engineers, but nobody gets it right the first time every time.  Because developers are moving at a break-neck pace, with practically every project being one that breaks new technology ground, bugs are the status quo.  In fact, each new firmware revision has a set of release notes that lists all of the known bugs with that release.  Of course, that doesn’t include the ones that VARs and end-users will find later.

I think it should be each vendor’s goal to eliminate as many known-and-fixable bugs as possible prior to releasing code.  Sure, some people do beta testing, but, as my mom used to say, “they give it a lick and a promise” and move right into FCS.  Some vendors push “innovation” so hard that they completely lose sight of the importance of the code working at all.  Sure, customers care about innovation, but they care alot more about the system working as designed, specified, and promised.  In the new State-of-the-Market report for 2009 from Webtorials, 64% of respondents chose reliability as the most important Wi-Fi system characteristic that they value.  In InformationWeek’s 2010 Analytics Report “Nothing but Air”, author and Wi-Fi consultant Grant Moerschel notes that 90% of respondents value reliability over any other system characteristic.  In other words, everyone agrees that Wi-Fi should “just work.”  Wi-Fi is more-or-less synonymous with the Internet, which makes it a de facto utility.  Your lights and water “just work” – why can’t you count on your Wi-Fi for the same kind of reliability?

How do we achieve this Utopian state of Wi-Fi affairs?  I’ll tell you how.  Just like Toyota…oops, wait…scratch that…let’s change industries…Apple Computer (ref: http://bit.ly/6F49C4), you have to design, design, design, and test, test, test.  Ever heard that old saying, “measure twice, cut once?”  I say, “test thrice, support nonce.” Hey, I made that saying up on the spot, so what can you expect?  How shalt we do such testing anywho?  Well, Aerohive uses VeriWave.  Their systems are crazy cool.  If you haven’t checked out their platforms, they do more than you can imagine.  You need 500 stateful clients coming out of one antenna?  No problem.  What about a mega-mix of 802.11b, g, and n for uplink and downlink stress and compatibility testing?  Piece of cake.  Just about all of the Wi-Fi manufacturers use their gear, and for good reason.  We have 4 of their systems (of varying size and configuration), and they’re used a ton around here.  Cabled, chambered, and over-the-air (OTA) automated testing happening just about around the clock.  It’s a testing extravaganza.

I tried to get the big boss man to send me one of those WT20 units for my own testing purposes, but…as you can imagine, that was met with a swift, “Uh, no.”  Rats.  A brother needs…OK, it’s really more “want” than “need”, but you know what I mean…a VeriWave system.  It would allow me to bat “clean-up” on this QA thing.  After test, test, and retest comes Devinator-the-Bug-Hunter-from-Hell.  It would be just like old times at CWNP when we were the free QA dept for every Wi-Fi vendor and their brother.

Shout out to Marcus Burton, lab engineer extraordinaire.  Woot!

Wireless 2.0 February 1, 2010

Posted by Devin Akin in : Uncategorized , 1 comment so far

Maximized Minimalization.  Yep, that’s what it’s all about.

What kind of wordsmith would I be if I had called the blog “less is more”? We’ve been saying, “Simpli-Fi” for a couple of months now, and we are beginning to wonder if anyone “gets it.”  Our existing customers get it, but for the unreached masses, there’s an important story here.

The enterprise Wi-Fi market is undergoing tremendous growth, with predictions of enterprise Wi-Fi market doubling in the next 3 years.  The way that Wi-Fi is being used and the requirements on an enterprise Wi-Fi network are also going through a fundamental and generational change, so much so, that we are calling it Wireless 2.0.  It’s not a new term, but it is a relevant one.

W2a

Today, there is an explosion of Wi-Fi enabled devices, a potential 10X client performance increase with the 802.11n amendment and the migration of Wi-Fi from convenience to mission-critical Ethernet replacement networks.  This is driving the enterprise to demand a new type of Wi-Fi infrastructure.  Enterprise’s want a secure, multi-service infrastructure capable of supporting different application (voice, video, data), user, and client types as though they each had their own networks.  A ubiquitously accessible, low-cost, mobile network with wired-like resilience and determinism, that is easy to use and deploy, is expected.  In other words, enterprises want the mobility and productivity of Wi-Fi with the scale, performance, resilience, and ubiquity of the Internet.

We believe the way to maximize in each of these areas is to minimize.  Let’s talk about how to do that.

Step 1 – Minimize Components

The controller was a stop-gap from the git-go.  Ask Bob O’Hara.  He’ll tell you.  Well, in fact, he did…right here:  Bob Speaks.

Controllers fixed some problems, and because there was such an insane demand for things like fast/secure roaming and radio resource management, controllers got their day in the sun.  Near the beginning of that time period, AP component prices were extremely high, so building the MAC-daddy (pun intended) AP was pointless.  Who would’ve bought them?  Not me.  Today is a completely different story.

Between then and now, there have been some very fast changes in the market.  The market went from needing only a shared control plane to needing that plus much more – like massive scalability and throughput support, near 100% uptime, and low cost.  It just so happened that right as controllers hit their peak, the economy hit the floor.

Aerohive’s architecture allows us to do in software what everyone else is doing in hardware.  Using hardware to share the control plane has severe scalability, cost, and resilience problems.  Remove the controller, and all of those problems go away.  That leaves us with only a management system (called HiveManager) and APs (called HiveAPs), which enables linear and unlimited scalability at a major cost reduction.

How much hardware are we talking about removing anyway?  Well, there’s the rack of controllers (depending on your network size), your branch office controllers, and even your redundant controllers.  How many controllers can you possibly need anyway?  Just wait until the 800 pound gorilla starts forcing you replace your edge switches with wired/wireless controllers (so that they can scale).  Your pocketbook is going to take it in the shorts even more then that it does now.

Step 2 – Minimize Costs

Removing all forms of controller evil from your network will get you half way there, but there’s more to the story when it comes to costs.  If you’ve recently bought a controller-based solution, you know this already.  There’s AP licenses, feature licenses (remote AP, firewall, WIPS, VPN, and so on – for all controllers including the redundant ones), and of course each controller maxes out at a certain number of APs…so that means more controllers.  Oh, I’m not done yet…  There’s also hidden costs like rack space and cooling as well.

Did I mention that protocols are free?  Aerohive does in software what everyone else does in hardware.  The competition will throw FUD all day long about “their APs costs more than ours” or “their management system costs more than ours”, but when you compare the solution cost with apples-to-apples features, they (meaning all of them) aren’t on the same playing field.  It’s actually quite funny to listen to our SEs’ stories about how the competition has to take all profit out of their quotes to even be competitive. J  I wonder how that’s working out for the competitors…

Aerohive also thinks that it’s very important to offer cost flexibility to its customers, offering a variety of APs and a variety of management solutions.  On the management side alone, HiveManager is offered as a 1U, 2U, HA, Virtual Appliance (Virtual Machine), and a SaaS (online) solution.  Which you choose depends on your organization’s size, shape, and budget type (CAPEX/OPEX).  HiveManager also comes in two “flavors” called Express and Enterprise.

I chose HiveManager Online (HMOL) Express to run my home network…but hey, that’s just me.  You can choose whichever you like since they all do basically the same things, just in a variety of delivery modes.

Step 3 – Minimize Failures

The End Game: adaptive, self-healing, self-optimizing, application-aware Wi-Fi infrastructure.  That’s what it’s about.  I like to describe it as “you can’t kill it.”  In this resilient infrastructure, there are no single points of failure, uptime is maximized to near 100%, and due to the minimal number of components, typically hardware failure rates (which affects every enterprise vendor in the same way) affect the customer less.

Aerohive achieves this goal through use of stringently-tested software capable of link-state, best-path forwarding at Layer-2.  Yes, Layer-2.  An AP dies, no problem.  An Ethernet switch dies, no big deal.  A cable gets cut, so what?  Think of Aerohive as a hybrid of the “mesh-only” vendors, that have mesh down to a science, and the access vendors who give it their best shot to do mesh (but just suck at it).  Built from the ground-up as a mesh/access hybrid, it functions like the Internet.  Think about how the routers on the Internet are autonomous, yet talk to each other through routing protocols (a control plane function).  Aerohive’s control plane protocol suite, called Cooperative Control, works like a Layer-2 routing protocol – managing control functions like RRM and fast/secure roaming.

A significant part of minimizing failures is through stringent QA testing to minimize compatibility and functional problems.  Nothing ships until a large group of testers (inside and outside the QA department) approves it.  Recent reports from InformationWeek and Webtorials both show that reliability is far-and-away (90% in one survey, 64% in the other) the most important vendor evaluation criteria.

Step 4 – Minimize Complexity

Am I the only one sick and tired of complex GUIs that give wireless network administrators a feature fatigue headache?  How about figuring out how to divide up groups of APs into individual controllers of varying capacities, licenses, and physical locations?  Deployment and configuration complexity is simply unnecessary.  Put the APs where they should be, based on a site survey, and be done with it.

Aerohive is pioneering the Automatic Wi-Fi Transmission (not trademarked in case you want to copy it). “Simpl-Fi” is plastered across our homepage.  We have recently launched HiveManager Online (HMOL) with Express and Enterprise options.  HMOL couldn’t be any easier: automatic provisioning, no appliance to worry about, automatic backups, fully redundant, etc.  The benefits go on and on.  Aerohive is taking the pain out of Wi-Fi.

Step 5 – Minimize Security Holes

Wi-Fi security is like Medusa (the Greek gorgon).  Hopefully that’s a clear enough mental picture.  You have to consider role-based access control (often just referred to as a role-based firewall these days), WIPS, 802.1X/EAP, PSK, secure management, and more.  Every which way you turn, there’s another security concern.

Aerohive covers all of these bases and then some.  For example, why would you want to use PSK when you can use Private PSK (PPSK)?  Aerohive’s founders and senior staff originated with NetScreen, which sold to Juniper.  Need I say more about security?  Holy smokes, these guys KNOW a little somethin-somethin about security. (sorry for the GA slang…couldn’t resist).

Summary

Anyone with a networking architecture background can easily see that all roads will eventually lead to a distributed architecture.  It’s the only way to scale, provide resilience, and to minimize costs. Look at your routed or switched networks.  Look at the Internet.  All distributed…everything at the edge. All the controller vendors are tinkering with their Wireless 1.0 architectures, distributing functions in a vain attempt to re-optimize themselves for a Wireless 2.0 world. Even Motorola and Cisco we hear. Aerohive has had a distributed approach for 3 years already. Do you want to trust a sub-optimal, half-baked product from the big boys or a third-gen, fully-mature product from the leader in controller-less Wi-Fi?  Hey, I’m just sayin’…