The definitive guide for evaluating enterprise WLAN networks

Copyright ©2014, Aerohive Networks, Inc. 1

2014 WLAN Buyer’s Guide

The definitive guide for evaluating enterprise WLAN networks


Introduction Only ten years ago, the idea of Wi-Fi as the primary access technology was little more than a vision. The WLANs of that period were designed primarily as convenience networks and were not well-suited for the operation of mission-critical applications and access. Over time, WLANs became increasingly pervasive and architectures evolved to better manage and contain WLAN traffic. For these convenience networks a model of centralized control and distinct points of presence via WLAN controllers eased the task of managing the increasing number of access points without overwhelming IT resources. This model was adequate for 802.11a/b/g deployments that really didn’t provide the robust network bandwidth and reliability to be a viable Ethernet replacement. The relatively low throughput of 802.11a/b/g networks also served to keep the centralized controller from being overwhelmed. The resulting centralized control model proved an effective way of “sandboxing” the wireless traffic and preventing it from disturbing traffic on the “main,” wired network.

With the advent of the 802.11n standard the wireless LAN has became firmly planted as a viable alternative for Ethernet, even in the case of mission-critical applications. 802.11n introduced high throughput, enhanced methods to overcome interference, and the level of reliability needed to make Wi-Fi into a foundation-layer infrastructure technology. WLANs had become required everywhere in organizations. The pervasive nature of 802.11n, however, caused the centralized “point-of-presence” controller model to break down for several reasons. One issue is the cost of deploying a centralized control over a distributed network. Other problems include the limitations on bandwidth that the controller introduced, as it creates a bottleneck from both a device and WAN backhaul perspective.

With today’s iEverything Enterprise, dominated by BYOD and the consumerization of IT, the barrier posed by centralized architectures that were intended to manage and secure WLANs of convenience is becoming increasingly intolerable. These trends provide compelling CapEx savings, but pose a challenge to a Wi-Fi network. Interestingly, as the endpoint devices become less sophisticated from a network intelligence standpoint, the onus of performing sophisticated services and security functions shifts to the network infrastructure. In other words, as devices get less intelligent about network services, the infrastructure must become more intelligent and automated to ensure that the simpler devices don’t become an administrative nightmare.

- 2014 is the year of Gigabit Wi-Fi - The 802.11ac standard has arrived, promising throughput of up to 1Gb per device. No longer can it be assumed that a centralized control model with distinct points-of-presence is suitable for WLANs running at high speed. If every client operates at up to 1Gbps, there is a high risk of significant bottlenecks that can impact any part of the network. The presence of a central control device, be it software or hardware based, in this scenario would be akin to introducing a traffic light into an eight-lane highway – all productivity would be dependent on the single device’s capacity to process data. When there are dozens of devices per access point running hundreds of megabits per second each across a dozens of access points, that capacity is reached very quickly.


Table Of Contents

Things To Consider ................................................................................................................. 4

Key Requirements .................................................................................................................. 6

Architectural Conclusions ..................................................................................................... 9

10 Things A WLAN Must Do ................................................................................................. 11

Using The RFP Process To Select A WLAN ......................................................................... 17


Things To Consider The evaluation of a Wi-Fi network requires that enterprises carefully consider the changes happening in the user population. While consumerization of IT and BYOD may be an overused term in networking today, it is unquestionably a driving factor in the Wi-Fi world. These phenomena drive the enterprise to deploy a wireless infrastructure, since many consumer devices don’t even have an Ethernet port. Additionally, three converging trends – cloud, mobility, and virtualization –allow business-critical work to be done just about anywhere on any device. That is a fundamental change that impacts IT first and foremost.

- Work has become a thing you do, not a place you go -

Architecturally, as the shift to wireless as a foundation-layer technology is made, one must consider future trends and their impact to the network. 802.11ac, capable today of speeds of up to 1.3Gbps, has a potential within a short timeframe to reach 3.5Gbps data rates. We will soon see mass adoption of the new standard within the next 2-3 years and therefore we must recognize and prepare for the changing traffic patterns on a network. As wired Ethernet progressed from 10Mbps to 100Mbps to 1Gbps to 10Gbps, the leaps in traffic were predictable and generally easy to calculate as endpoints were relatively static and the traffic increase was simply a factor of 10. Mobility with high data rates changes this on two vectors.

First is the sheer volume of data, which becomes an exponential. By upgrading a single access point to support the higher 802.11ac data rates you must now consider all the “upstream” links to this traffic. Where the data is forwarded to and from becomes critical. You cannot have point-to-point data forwarded to a central control point; it absolutely must be locally forwarded, and policy must be enforced locally as well. Switching infrastructure can be upgraded to support dozens of potentially multi-gigabit AP links, but the bottleneck imposed by a central controller would be untenable. Therefore the intelligence, policy enforcement, and network services need to be locally enforced, not centrally.

Second is the fact that these high-speed clients are, in fact, mobile. This makes load balancing across the infrastructure paramount. If you architect a network to forward data to a central control point, as it is in the controller-based model, there is no way to balance multiple Gbps of data across the controllers. The architecture’s inherent limitations will leave you with little choice but to re-architect the network and invest large amounts of time and money. The fact is that even though 802.11ac is in the future, it must be architected for today in order to handle both mobility and high bandwidth clients.

With BYOD a primary factor in networks deployed today there are many important considerations that should be reviewed. These considerations can generally be categorized and analyzed in two distinct parts:

Onboarding of devices: this encompasses how devices are brought on to the network and how policy is applied. This includes authentication, device type identification, enterprise access policy and the application of context, such as device-type, user ID and location of the policy that is applied to that particular device.


Providing service to the device once it’s onboard: this includes how the devices, which are neither owned nor managed by the IT department, access corporate network services like file sharing, printing, video conferencing, etc.

BYOD is about more than “onboarding” mobile devices. It must include a means to make them useful and productive members of the corporate community. Once safely and securely on the network, you must consider how to enable added value.

As with any IT investment there is the consideration of WLAN cost predictability. IT must be able to compare “apples-to-apples” when generating comparisons between wireless vendors, and it is important to understand how much comparisons vary depending on feature set. In many cases, this means that IT should review not only the cost of the hardware, but the cost of any licenses that are needed to make the WLAN perform as specified. Cost considerations should also include “soft” costs, such as the cost of operating the solution. Most enterprises do not have a Wi-Fi expert on staff; in many branches, there is not even an in-house IT staff. WLAN management should mirror security and access policies in use on the wired network, and should provide for easy, seamless upgrades; all without requiring RF expertise.

Another important element of cost is scalability. Few people could have foreseen the iEverything explosion when considering their initial Wi-Fi network. Any Wi-Fi network under consideration today should take into account the fact that the deployment will be required to scale to accommodate more devices, more users, more heavy applications, and, of course, newer, faster WLAN technology. It is clearly untenable to put in a Wi-Fi solution that is “maxed out” at 802.11ac.


Key Requirements

There are a number of requirements that must be closely examined when considering a WLAN purchase. As Wi-Fi moves to the primary access method, consumerization of IT and BYOD drive the demand for reliable, high-performance access, and contextual policies become the norm, it is not sufficient to consider a WLAN vendor that is doing “business as usual” Wireless gear that was included at low or no cost as part of a larger networking equipment buy was understandable when the WLAN was a convenience-only addition to the wired network. No enterprise, however, will find this reasoning acceptable as Wi-Fi becomes the primary means of accessing corporate resources, and the carrier of mission-critical applications.

Architectural Considerations The fundamental architecture of wired networks has probably not been considered by most IT professionals since the advent of Fast Ethernet. While there have certainly been advances in how to get the most out of the wired network, the underlying technology is very well understood. This is not the case in wireless networking, where many of today’s leading vendors base their implementations upon the usage expectations of legacy convenience networks that were prevalent a decade ago. While Wi-Fi technology has advanced exponentially since 2001, it is important to consider whether WLAN vendors have actually changed their architecture to be more seamlessly integrated into well-known network architectures (core, distribution, access) and their traffic flows, or if they have an expectation that the network architecture will change to accommodate their WLAN solution.

Three Planes Any consideration of WLAN technology necessarily begins with a brief discussion of the architectures derived from the traffic components themselves, since it is from them that the Wi-Fi network is built. Wireless traffic is commonly abstracted into three planes, which include:

The Control Plane The need to handle control plane traffic was the basis upon which many WLAN vendors built their underlying architecture over the last decade. In general, control plane traffic is anything that is needed to get wireless functioning in a coordinated, multi-AP network; it can be considered the “signaling” of the network. Control plane packets are destined for, or originated by, the WLAN equipment itself.

Vendors introduced the concept of a centralized control devices, or controllers, to handle control plane traffic in 2001. It is important to note that this architecture was not necessarily based on the fact that a centralized model was the optimal method to handle all traffic including control packets; rather, it was the most effective way to enable processing in a wireless network while still keeping it affordable given the technology of the time. Ten years of processor development have led to processors that are far more powerful while at the same time exponentially less expensive, so it is now possible to enable control plane processing in a distributed model. Interestingly, many vendors continue to advocate a central controller architecture in one form or the other. This is primarily a legacy issue, as it would require a complete system redesign for these vendors to move to a distributed control model (see below). Other


vendors have designed their systems from the ground up for pervasive, high-speed Wi-Fi and have found ways to use advanced processing capabilities to create a new, completely distributed architecture that closely resembles the control plane common among routing architectures. In this model, control information, including link and user state, is passed from AP to AP, without the need for a central control point in any form.

The Data Plane The data plane, sometimes referred to as the data forwarding plane, is basically the traffic that goes through a WLAN device but not to those devices. The data plane is generally distributed, however in a central control architecture many policy decisions are handled by the central control device; therefore the data plane is often required to go through the controller in order to have policy enforced, including application visibility and control (AVC), QoS, deep packet inspection, flow classification, etc.

The Management Plane Management plane traffic carries the operations and administration traffic required for network management. It is most effective to centralize management to enable easy, consistent policy application. Management plane traffic has no functional impact on real-time operation of the network.

These elements of WLAN traffic have spawned several different architectures, including:

• Central controller

• Central controller with distributed forwarding

• Distributed control and forwarding

Figure 1 - Legacy Centralized and Modern Distributed Intelligence WLAN Architectures


Central Control Model The concept of a central controller is derived from a lack of sufficient, affordable processing power to handle both control and data functions at the AP. According to industry veteran Bob O’Hara, one of the originators of this architecture:

“Centralized controllers were never the ‘right’ way to handle control traffic. They were created because that was one of the only ways to handle the problem given the balance between cost and processing power in 2001.”

The industry is coming to understand the inherent limitations of a centralized controller model, including cost, latency, and single point of failure because of modern day realities such as BYOD and high-speed, low cost consumer devices supporting cloud connected applications.

Some vendors who have architected their system around a central control model have come up with less expensive ways of delivering controller functions which include:

Cloud-based control One method for disguising a central controller is to put it in the cloud. In this situation, there is no need to put a controller into the data center, or to manage a physical piece of hardware. Control packets responsible for functions such as roaming, session state across APs and subnets, etc., are sent to and from the Cloud via an Internet connection. Regardless of where the controller is located, however, it is important to realize that it is still there, and that any disturbance in getting traffic to the device will affect overall WLAN traffic and network capability.

Central control and distributed traffic forwarding In a distributed forwarding model local traffic (i.e., traffic originated and destined for a local resource) is forwarded between APs and not back to the controller. The important thing to remember, however, is that the fundamental architecture – that is, the centralized controller running control plane functions – is unchanged in this model. Traffic that is forwarded between APs is therefore not subject to features that are only garnered via a trip through the controller. Some examples of features not employed in a distributed traffic forwarding model could include policy enforcement, authentication, deep packet inspection, or Quality of Service.

Distributed Control and Forwarding Model Still another type of architecture takes advantage of the exponential increase in processing speed/power and the attendant decrease in cost to put both the data plane and control plane functions on the AP, removing the central controller altogether. The resulting architecture looks more like the Internet, with no central point of failure and a completely distributed control plane coordinating the communication and exchanging state with advanced protocols. If a problem occurs, the APs in this model are able to dynamically route around it maintaining full state and operation. This makes the architecture extremely resilient and flexible, while at the same time making it more affordable because there is no additional equipment beyond the APs. Because a WLAN with distributed control and intelligence functions more like a grid computer, it can also act on an extremely high volume of control and policy decisions made at the edge of the network without having to forward everything to be processed by a separate device. This increases overall network performance and enables true QoS.


Architectural Conclusions This quick examination of Wi-Fi network architectures highlights several considerations. First, the data plane must be distributed. Considering the explosion of high-speed devices and the BYOD phenomenon this is a given in any network. The second is that management must be centralized to enable easy, consistent views of network operations for more efficient problem resolution and minimal interruption of service; central management is largely also considered a given. The fact that management is centralized, however, does not necessarily imply that it must be located on premise, in a piece of hardware. Because management traffic is out-of-band, a management device can easily be located in the cloud and still be completely effective.

“By 2015, 80 percent of newly installed wireless networks will be obsolete because of poor planning - Gartner” The majority of differences between Wi-Fi architectures today concern the control plane. Legacy models feature a central controller, housed in hardware. Newer models have put this central controller into the cloud; it’s important to realize, however, that unlike management traffic, control plane information must be constant and uninterrupted as it has direct functional impact on the WLAN. Therefore, while a cloud-based controller could lower overall costs, it can still be a liability to resilience and performance. Some legacy controller vendors have implemented distributed forwarding, in which traffic is passed directly from AP to AP, without the benefit of control plane information. While this model may work in some situations, it falls short in many others where security and QoS features (among others) are essential and require higher level, compute-intensive functions are performed by a central controller. Finally, some vendors have taken advantage of low-cost processing power to pass control plane information from AP to AP. This approach enables higher speed clients to be supported, distributes processing for increased capacity, future-proofs the network, and provides full functionality without any single point of failure.


1 - http://forwardthinking.pcmag.com/none/289313-gartner-why-enterprise-wireless-is-not-ready-for-the-mobile-explosion


10 Things A WLAN Must Do The combination of the iEverything explosion with the speed and reliability of 802.11ac has created a compelling case for Wi-Fi as the primary access layer. Unfortunately for the WLAN buyer, there is no longer a single architectural model from which to choose, and legacy vendors may obscure underlying issues as they seek to retain their revenue base. In order to make the right decision for your network, you should consider the following areas to ensure that the WLAN you choose will satisfy immediate requirements while enabling you to be prepared for the future:

• Integrating BYOD and company-owned consumer devices has become a vital part of every network, from corporate office to primary school campus. Securing these devices as they come on to the network and making them productive tools as part of the network are the keys to taming the iEverything explosion.

• Deployment, installation and maintenance, which includes the initial setup and deployment, as well as the day-to-day issues of management, both in the corporate office as well as in branches.

• Cost, which includes the price of the hardware, operating expenses and feature licenses.

• Security, which is vital for a primary access method running mission critical applications. Security must be ensured for all user, device and application types, in all locations.

• Performance, which must be optimal for a variety of clients, users, application types and protocols – including heavy applications like voice/video and virtualized or cloud-based apps.

• Scalability, which is a key requirement as client loads increase, new sites are opened and new applications are developed.

Management and Deployment of BYOD and Company-owned Consumer Devices Your WLAN must be able to enforce corporate policy based on user identity and fingerprint of their device

• Business case: Although consumer-level devices used to be thought of as exactly that – consumer level – public and private cloud computing as well as technologies like desktop virtualization have enabled these devices to become productivity tools for corporate operations. Onboarding these to the network needs to be as straightforward as a login from any corporate laptop, and policy enforcement needs to be automatic so as to ease any operational headaches or unnecessary support calls to the helpdesk. Additionally, if a guest device or a device of a non-employee is allowed on the network it is important that their communication be secured. Examples include students in a school that require privacy, or a contractor in an enterprise that, while not an employee, still deals with sensitive, company confidential information.


• Requirement: The optimal WLAN will have the inherent capability to tie to corporate LDAP services and automatically fingerprint the device coming on the network. Security and quality of service (QoS) policies should be established based on the users’ context (identity, device type, location, and application) and not solely on the type of connection (wired, wireless, SSID, etc.). Further, dynamic, configurable pre-shared keys that are unique to each guest and can be configured to expire should protect guest connections. These features together will provide context-aware policy enforcement and safely onboard devices to the network. Determine the services required for your BYOD environment, as you may want to extend guest management capabilities even further.

Your WLAN should provide service to BYOD devices once onboarded

• Business case: Once a BYOD device is onboard your network, the key question is what the user community will do with that device. Having the ability to surf the Internet and retrieve email provides little return on investment (ROI) for your BYOD initiative. In order to provide true ROI for BYOD you need to make these devices into productive corporate tools. At a minimum, employees should be able to print and project presentations, share files and use collaboration software. Without these basic capabilities the investment in a BYOD initiative boils down to giving an iPad user access to the Internet or other cloud services for quick reference, but does not alleviate the responsibility of giving an employee the tools needed to replace the corporate laptop with a personally owned tablet; hence, it doesn’t allow you to benefit from the CapEx savings promised by BYOD. One problem to avoid is the need to configure every device, because this will immediately erode all BYOD benefits via costly helpdesk calls.

• Requirement: The optimal WLAN should be “service-aware”; that is, it should have an understanding of network services available to BYOD devices and provide a means of making those services usable by BYOD devices without “hands-on” configuration. The vast majority of employee-owned devices that are intended to be used on the company or school networks are based on Apple iOS. Therefore creating a way to enable Apple’s “Zero-Configuration Networking,” or Bonjour, available corporate-wide in an efficient, predictable manner is critical to a successful WLAN deployment.

Deployment, Installation and Maintenance Your WLAN should have a single consistent architecture that scales in both capital and operational costs

• Business case: As discussed above, different WLAN approaches have different implications on how data forwarding and control traffic are handled. The impact of how the architecture is implemented can very quickly increase the cost of deployment and maintenance. Some vendors offer as many as three different architectures – large controller, virtual controller, and small APs – that simply bridge traffic blindly. The problem is the cost of implementation and maintenance varies based on the size and geographic location of each site. Which do I use where? Controller? Virtual Controller? How large a controller to buy? If each site has a different architecture, what will licenses cost at each site? When the IT admins troubleshoot a problem at a site all the same questions must be asked every time, because each architecture will require a different methodology for problem isolation and resolution based on the network deployed.

• Requirements: The optimal WLAN will use a single network architecture regardless of size and still provide reasonable costs. Whether the deployment features a single AP at a small site, 10 APs at a


medium site, or 1000 APs at a large site, the basic underlying architecture should be the same. This allows the advantages and ROI of repeatability of network deployment and maintenance.

Your WLAN must be easy for IT to manage, maintain and upgrade

• Business case: In networking, change is the only thing that stays the same. As new deployments come on line, new security or access policies are developed and new applications become available, it must be easy to enable the Wi-Fi network to keep pace. This quality is essential as WLAN moves to the primary access method. To ensure consistency, WLAN management should be a centralized function, and ideally should operate identically whether housed in the cloud or on the premises.

• Requirements: The optimal WLAN should be easy to manage, maintain and upgrade. This is true not only in the corporate headquarters, but in remote or branch offices as well, to ensure consistent security and policy. Management actions and commands should be written in language that is easy for a non-RF expert to understand.

Your WLAN must facilitate easy troubleshooting

• Business case: Particularly in the era of BYOD, it is vital that the WLAN be easy to troubleshoot. In many cases, consumer mobile devices are optimized for battery life, not for radio transmission – but the end user will not be aware of that. All they will see is that the wireless network isn’t working! It is important to be able to visualize the problem without RF expertise and to quickly track down the primary issue.

• Requirements: The optimal WLAN will be one in which it is easy to see the cause of a problem without having to troll through heaps of incomprehensible, RF-centric logs. AP and user performance should be easy to find quickly and should enable the speedy pinpointing of the issue, which may not be related to the wireless network at all. It is important that the WLAN provide a means to view a problem all the way down to client-level statistics for faster, more accurate problem isolation even at remote locations.

Cost Your WLAN must feature predictable capital expenditure

• Business case: When considering capital expenditures, it is tempting to look at only the cost of the access points, but this is not the whole story. If a central controller is part of your considerations, examine what it will cost to enable your current deployment. Then consider how the same equipment will fare if you double your user count, increase your traffic load or move to more space. Is a larger controller required? If so, is it still cost effective? Also consider the number of sites your organization has. If considering a controller-based WLAN, does each site need a controller? If so, what size and what if that site grows or moves? What about redundancy? Don’t forget to double your controller count. Another consideration is that of feature licenses. Often the base hardware solution does not actually enable the firewall, security, QoS or policy features that you actually need.

• Requirements: Ask for a full list of equipment and licenses required to handle your Wi-Fi networking needs today. Then double the deployment and see what hardware and licenses would need to be added. If there is a controller and there is a point at which the controller you are looking at will need to be amended, find out what that point is.


Your WLAN must minimalize operating expense

• Business case: As most networking professionals know, the highest cost element in most deployments isn’t the capital expenditures; it’s what is required to keep the network running. Consider these factors:

- What is the management interface like?

- What are the steps required to specify a deployment?

- What are the steps required to deploy the solution?

- How easy is it to visualize a user problem?

- What would I need to do in order to expand this WLAN to more floors/offices if I purchased it?

- Can I deploy the same architecture in my branch office? If not, why not?

- What is the company’s history in WLAN upgrades and advances? Have they ever introduced upgrades that are not fully backward compatible?

• Requirements: The ideal WLAN must have a low operating expense. This includes both how easy it is to get a full list of equipment required; the requirements for a deployment both in corporate offices and in branch office; the ease of maintenance and upgrades; and the ability to troubleshoot the system both in branch offices and headquarters without the need for RF engineers to be dispatched to every location. It is important to understand how this is achieved.

Security Your WLAN must feature enterprise class security

• Business case: The iEverything explosion has enabled incredible business productivity, but it has also created a myriad of new openings for network security threats. In order to be truly enterprise-class, your WLAN must have comparable security to that found in your wired network. Advanced security is considered a feature by some vendors and licensing for it comes at a cost; you must ensure that these features are included in your initial estimate, along with any costs for upgrades and expansion.

• Requirements: The ideal solution must enforce advanced security features, and these features must be included in the initial cost overview.

- Wireless Privacy and Key Management – using keys to encrypt and secure traffic transmitted across the air.

- Authentication – identifying users as they come on the network. This means authenticating employees as well as guests and contractors. Also determining whether RADIUS, Active Directory or LDAP is used for authentication. Your WLAN solution must ensure consistent security at all times.


- Identity Based Access Control – using the identity of a client to provide access to the correct VLAN, and allow or deny access to specific applications or resources.

- Device Physical Security and Data Storage – ensuring the networking platform itself is securely implemented so that it cannot be compromised – even if stolen.

- Application Visibility and Control – having complete layer 7 awareness at the edge of the network ensures that mobile devices utilize productive applications only

• Business case: No one knows where the next network threat could come from, or when it will hit. Your WLAN must therefore have security enabled at all times, and for all traffic types security must remain consistent and in place even if the WAN is down. It should not be sacrificed for the appearance of a lower cost.

• Requirements: Ensure that any solution under consideration provides consistent security at all times. If the vendor is pitching distributed or local forwarding, make sure that you understand what security features, if any, are omitted when traffic bypasses the controller. If a branch or cloud-based controller solution is dependent upon the WAN for security applications, be sure to fully consider what features will fail if the WAN does.

High Performance Your WLAN must provide high performance throughput

• Business case: The WLAN is now being considered as a primary access method largely because of the throughput provided by 802.11ac. The consumerization of IT means that users are intolerant of latency, even when it may be a factor of a lower powered battery in their mobile device. Users are also becoming more and more dependent upon high bandwidth applications, like voice or video, and low throughput or high latency solutions are simply not up to the task of handling these “heavy” applications.

• Requirements: The WLAN solution must be able to ensure Quality of Service for VoIP, video or other heavy application traffic, restrict unwanted applications such as torrents, and handle legacy clients as well as 802.11ac clients. Many vendors will charge for the licenses you need, so be sure that they are included in any solution that is considered.

Scalability Your WLAN must grow with your organization without barriers

• Business case: When WLANs were considered a convenience network, scalability was not a large factor in choosing the right equipment. As Wi-Fi moves into the primary access method, however, the WLAN must scale. Consideration of scalability applies both to increasing the coverage of a deployment and increasing the load on that deployment. You should also look at what is necessary to deploy remote or branch locations. If this requires the deployment of a new controller, or makes the branch subject to variability in the WAN connection, it may not be the best solution for you. It is also important to consider feature licenses as part of the cost and complexity; as a solution scales it could complicate operations significantly.


• Requirements: The WLAN should scale predictably, including hardware and software. New deployments should offer consistent features. You should also examine what is required to scale a deployment up in terms of operating expenses.


Using The RFP Process To Select A WLAN

Most companies will use the RFP as a way to narrow the list of possible WLAN vendors to consider. In the last section we overviewed 10 things a WLAN must do. In this section, we’ll show how to use those requirements as part of an RFP process. The majority of these considerations should be included under the Scope of Work section, in which the RFP requests a detailed list of the business and technical requirements. This section will give you a starting point for your WLAN RFP and initial “things to think about” while building your RFP.

Overview of Proposed Solution – Architecture This is a good place to ask the vendor to outline the architectural model that they are proposing. This is also an appropriate section to request a complete parts list for the solution under discussion.

• Look for controllers – This gear may be on premise hardware, cloud-based, or can even be located in a corporate office deployment if the proposal is for branch networks. If a controller is listed, pay close attention to how the vendor answers these later questions:

- Scalability – Does the use of a controller also bring with it a “stair step” cost model? If the deployment expands, at what point would you need to add another controller?

- WAN Outage – If the vendor uses a cloud-based controller, or relies on a corporate controller to power branch WLANs, ask what features are disabled in the case of a WAN outage. Do end users need to reauthenticate in such an instance?

• Look for feature licenses – Some vendors’ base systems are virtually useless without features that are enabled via license. If licenses exist, they may be included at no charge with the base system. In such cases, be sure to ask how the cost changes if the deployment grows.

Technical Specifications Capacity and Scalability In this section, look for the number of access points specified for each site under consideration. They should also call out the client capacities of each AP/deployment. You may request that the deployment be specified for headquarters and branch locations. You can also look for:

• Wi-Fi Planning Tool – some vendors will provide a Wi-Fi planning tool, either at no charge or as part of purchase. This tool will enable you to see the reasoning behind the gear that the vendor is specifying, and how that can change if your requirements change.


• Feature Licenses – In many cases, functionality is enabled via license. Are these licenses included with the gear? What if a site is added?

Outage Management This section should describe how the system functions in the case of an outage, whether of the outage involves a piece of the WLAN gear or the WAN, and could include:

• WLAN Controller Outage – What happens if a WLAN controller fails? If a system is billed as resilient, look to see if this claim is supported by a backup controller.

• Access Point Outage – What happens if an access point fails? Is traffic dropped? Are there any “self-healing” capabilities in the system?

• WAN Outage – This area is significant if the WLAN architecture is dependent upon a cloud-based controller, or if a branch deployment relies on a controller in HQ. Does the WLAN continue to pass traffic in the case of a WAN outage? If yes, what features are disabled? Consider how important these features are to your business and whether you are comfortable without them. What happens when the WAN connection is restored? Are sessions maintained? Do users need to reauthenticate?

Protocol Support and Radio Frequency (RF) Management This section should call out which protocols are supported as well as what elements of RF management are supported by the system. Additional areas to consider include:

• Wireless standard support – Any WLAN under consideration should support 802.11ac/n/a/b/g. Additional questions include:

- System functionality in a mixed client environment – This is a very important consideration for several reasons. 802.11ac clients can “drown out” n/a/b/g clients in some situations. Conversely, an .11a/b/g/n client can also functionally dominate the air because of the greater time required to pass traffic in comparison to .11ac clients. In either situation, there will be a percentage of users that are unhappy, so how they are handled should be examined.

• Client Band Steering – Any WLAN under consideration, particularly those with BYOD initiatives, should be able to dynamically balance clients to their ideal frequency band.

- Frequency band steering in the unlicensed spectrum – Moving user traffic to the 5 GHz radio band (802.11ac and 802.11na) is a long-standing technique to increase total throughput on an 802.11 network. Total area throughput is limited by the number of channels that can be saturated, so the greater the number of non-overlapping channels available, the greater the possible throughput. Furthermore, the noise floor on 5 GHz channels is often lower due to the smaller number of unlicensed devices.

Power Management


This section should describe the features and controls required for power management of the WLAN access points. Specific details here may include access points that are capable of operating at both Power over Ethernet (PoE) modes, 802.3af (low) and 802.3at (high).

Quality of Service (QoS) This section should describe overall enterprise QoS requirements for business applications (e.g. Voice over WLAN, video conferencing, etc.).

Security This section should describe how the WLAN provides security, as well as how it will interact with existing network security specifications. Be sure that responses address any regulatory compliance requirements, including HIPAA, PCI-DSS and more. Details could include firewalling, Application Visibility and Control (AVC), Wireless Intrusion Detection (WIDS), network access control, security event management, authentication methodology, identity-based access controls, and rogue AP detection. Additional considerations include:

• Security features enabled via license – Are any of the security capabilities described by the vendor enabled via licenses? If yes, what are the costs? If the license cost is included with the base system, how is it enabled if the deployment expands?

BYOD support BYOD support is a relatively new requirement, but must be considered for any new Wi-Fi network under consideration. Specific elements to look at include:

• How is a BYOD device onboarded onto the network?

• Does the system enable a means to ensure policy consistency across user-owned devices?

• How do BYOD participants print, share files, or use projectors?

Deployment and Configuration In this section, the vendor should specify the steps required to deploy the WLAN. This should include any preplanning capabilities. In addition to consideration of how to deploy the WLAN at Corporate or HQ, it is vital to consider:

• LDAP Integration – Does the system integrate consistently with corporate identity services? If so, how?

• Branch deployment – how does the solution scale? How are branches connected to HQ?

• Technical expertise – What level of technical expertise is required to set up the WLAN, particularly in branch locations? What does the person installing the system need to know about networking in general and about RF in particular? If there are problems, how easy is the deployment to troubleshoot?

Systems Management


It is crucial to thoroughly understand the systems management capabilities of any WLAN being considered, since this will be the largest ongoing expense of the overall deployment. The vendor should list and clearly describe every element of the central management system required. Additional considerations include:

• Web interface – Can the management UI be accessed via the Web?

• Management capabilities via license – In some situations, vendors will integrate basic management functionality but charge for additional capabilities. Make sure you know what is available as part of the system and what will cost more. Also consider what additional licenses, if any, are required when scaling the WLAN or extending it to branch locations.

• Management device flexibility – If management is handled via a centralized device, is an additional device required for branch locations? Is there a cloud offering for management?

• RF expertise required – Consider what level of RF expertise is required to work with the management interface. Could someone with a general understanding of networking operate the system?

Quality of Service/Service Level Agreement As WLAN becomes the primary access layer, it must support rich applications, many of which have strong QoS requirements. To what degree does the management interface support the separation and prioritization of this traffic? Is it possible to enable an enforceable SLA with this system? If yes, how does the process function? Is it automatic, or does it require end user intervention?

Troubleshooting WLAN is subject to a variety of issues that are unique to RF. For the WLAN to be useful, it must be easy to pinpoint problems as they come up, sometimes by user. Consider:

• Per-user throughput/issues – Does the management interface allow you to see throughput and performance by user? If there is a problem, how easy is it to see the nature of the issue; that is, can you quickly and easily determine if the problem is the network overall, the application itself, or the WLAN? How easy is it to make prioritization changes?

• RF expertise required – While RF faces unique challenges, it is very unlikely that each office/branch will have an RF expert onsite. What level of RF expertise is required to understand issues? To what degree would an administrator need to sort through RF-based logs to understand a reported problem?


About Aerohive

Aerohive Networks reduces the cost and complexity of today’s networks with cloud-enabled, distributed Wi-Fi and routing solutions for enterprises and medium sized companies including branch offices and teleworkers. Aerohive’s award-winning cooperative control Wi-Fi architecture, public or private cloud-enabled network management, routing and VPN solutions eliminate costly controllers and single points of failure. This gives its customers mission critical reliability with granular security and policy enforcement and the ability to start small and expand without limitations. Aerohive was founded in 2006 and is headquartered in Sunnyvale, Calif. The company’s investors include Kleiner Perkins Caufield & Byers, Lightspeed Venture Partners, Northern Light Venture Capital and New Enterprise Associates, Inc. (NEA).

Corporate Headquarters Aerohive Networks, Inc. 330 Gibraltar Drive Sunnyvale, California 94089 USA Phone: 408.510.6100 Toll Free: 1.866.918.9918 Fax: 408.510.6199 [email protected] www.aerohive.com

International Headquarters Aerohive Networks Europe LTD The Courtyard 16-18 West Street Surrey, UK GU9 7DR +44 (0)1252 736590 Fax: +44 (0) 1252711901

Technology

The definitive guide for evaluating enterprise WLAN networks