Aerohive WLAN Eval Guide 2012 2013

Copyright 2012, Aerohive Networks, Inc.
1

2012-2013
WLAN Buyers Guide
The definitive guide for evaluating enterprise WLAN networks

Copyright 2012, Aerohive Networks, Inc. 2

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 didnt 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 become 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 have become required everywhere in organizations. The pervasive nature of
802.11n, however, causes 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 todays 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 dont become an administrative nightmare.
802.11n is the standard of choice today, but it is not the terminal point of the growth of WLAN speed or
performance. The 802.11ac standard is on the horizon, promising throughput of up to 1Gb (1Gps?) per device. A
key issue to understand is that while this standard isnt available today, it must be considered now because of the
degree to which it will impact network architecture. 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 devices 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 ................................................................................................. 10
Using The RFP Process To Select A WLAN ......................................................................... 16


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 dont 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. Work has become a thing you do, not a place you go. That is a fundamental change that impacts IT first
and foremost.
Architecturally, as the shift to wireless as a foundation-layer technology is made, one must consider future trends
and their impact to the network. As mentioned earlier, 802.11ac, with its potential for 1Gbps data rates, is just
over the horizon. It is far enough away from mass deployment (3-5 years) that the casual user may not see a
reason for concern with what they are doing today, but the reality is that when architecting a network today for
wireless access, the bandwidth and throughput it represents fundamentally changes the high throughput 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 architectures
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 its 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 the 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.11n.


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 todays 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 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
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 OHara, 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.
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.
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; its 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 be 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.


10 Things A WLAN Must Do
The combination of the iEverything explosion with the speed and reliability of 802.11n 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 and device 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; this is a minimum requirement of any system and
shouldnt be an additional cost.
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 doesnt 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 Apples 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 vary 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 isnt 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? 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
isnt the capital expenditures; its 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 companys 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.
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.11n. 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 handle VOIP, video or other heavy traffic, which
requires optimal performance, a means to handle legacy clients as well as 802.11n clients, and a way to
ensure Quality of Service. Many vendors will charge for the licenses you need, so be sure that they are
included in any solution that is considered.
Scalability
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, well 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 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.11n/a/b/g. Additional
questions include:
- System functionality in a mixed client environment This is a very important consideration
for several reasons. 802.11n clients can drown out a/b/g clients in some situations. Conversely,
an .11a/b/g client can also functionally dominate the air because of the greater time required to
pass traffic in comparison to .11n clients. In either situation, there will be a percentage of users
that are unhappy, so how they are handled should be examined.
- Architectural functionality in an 802.11ac environment This standard is far from ratified, but
recent experience with 802.11n shows that it is likely that pre-standard chipsets will emerge at
some point. This section can show how the vendors architecture is prepared for the future.
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.11a 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, 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 todays networks with cloud-enabled,
distributed Wi-Fi and routing solutions for enterprises and medium sized companies including
branch offices and teleworkers. Aerohives 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
companys 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
info@aerohive.com
www.aerohive.com

EMEA Headquarters
Aerohive Networks Europe LTD
Sequel House
The Hart
Surrey, UK GU9 7HW
+44 (0)1252 736590
Fax: +44 (0) 1252711901

Aerohive WLAN Eval Guide 2012 2013

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aerohive WLAN Eval Guide 2012 2013

Uploaded by

Copyright:

Available Formats

Copyright 2012, Aerohive Networks, Inc.

You might also like