Aerohive wlan-buyers-guide 2012-2013


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Aerohive wlan-buyers-guide 2012-2013

  1. 1. 2012-2013 WLAN Buyer’s Guide The definitive guide for evaluating enterprise WLAN networksCopyright ©2012, Aerohive Networks, Inc. 1
  2. 2. IntroductionOnly ten years ago, the idea of Wi-Fi as the primary access technology was little more than a vision. The WLANsof that period were designed primarily as convenience networks and were not well-suited for the operation ofmission-critical applications and access. Over time, WLANs became increasingly pervasive and architecturesevolved to better manage and contain WLAN traffic. For these convenience networks a model of centralizedcontrol and distinct points of presence via WLAN controllers eased the task of managing the increasing number ofaccess points without overwhelming IT resources. This model was adequate for 802.11a/b/g deployments thatreally didn’t provide the robust network bandwidth and reliability to be a viable Ethernet replacement. Therelatively low throughput of 802.11a/b/g networks also served to keep the centralized controller from beingoverwhelmed. The resulting centralized control model proved an effective way of “sandboxing” the wireless trafficand 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 forEthernet, even in the case of mission-critical applications. 802.11n introduced high throughput, enhancedmethods to overcome interference, and the level of reliability needed to make Wi-Fi into a foundation-layerinfrastructure technology. WLANs have become required everywhere in organizations. The pervasive nature of802.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 thelimitations on bandwidth that the controller introduced, as it creates a bottleneck from both a device and WANbackhaul perspective.With today’s iEverything Enterprise, dominated by BYOD and the consumerization of IT, the barrier posed bycentralized architectures that were intended to manage and secure WLANs of convenience is becomingincreasingly intolerable. These trends provide compelling CapEx savings, but pose a challenge to a Wi-Finetwork. 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 otherwords, as devices get less intelligent about network services, the infrastructure must become more intelligent andautomated to ensure that the simpler devices don’t 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 orperformance. The 802.11ac standard is on the horizon, promising throughput of up to 1Gb (1Gps?) per device. Akey issue to understand is that while this standard isn’t available today, it must be considered now because of thedegree to which it will impact network architecture. No longer can it be assumed that a centralized control modelwith distinct points-of-presence is suitable for WLANs running at high speed. If every client operates at up to1Gbps, there is a high risk of significant bottlenecks that can impact any part of the network. The presence of acentral control device, be it software or hardware based, in this scenario would be akin to introducing a traffic lightinto 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 adozens of access points, that capacity is reached very quickly.Copyright ©2012, Aerohive Networks, Inc. 2
  3. 3. 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  Copyright ©2012, Aerohive Networks, Inc. 3
  4. 4. Things To ConsiderThe evaluation of a Wi-Fi network requires that enterprises carefully consider the changes happening in the userpopulation. While consumerization of IT and BYOD may be an overused term in networking today, it isunquestionably a driving factor in the Wi-Fi world. These phenomena drive the enterprise to deploy a wirelessinfrastructure, since many consumer devices don’t even have an Ethernet port. Additionally, three convergingtrends – cloud, mobility, and virtualization –allow business-critical work to be done just about anywhere on anydevice. Work has become a thing you do, not a place you go. That is a fundamental change that impacts IT firstand foremost.Architecturally, as the shift to wireless as a foundation-layer technology is made, one must consider future trendsand their impact to the network. As mentioned earlier, 802.11ac, with its potential for 1Gbps data rates, is justover the horizon. It is far enough away from mass deployment (3-5 years) that the casual user may not see areason for concern with what they are doing today, but the reality is that when architecting a network today forwireless access, the bandwidth and throughput it represents fundamentally changes the high throughput trafficpatterns on a network. As wired Ethernet progressed from 10Mbps to 100Mbps to 1Gbps to 10Gbps, the leaps intraffic were predictable and generally easy to calculate as endpoints were relatively static and the traffic increasewas 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 supportthe higher 802.11ac data rates you must now consider all the “upstream” links to this traffic. Where the data isforwarded to and from becomes critical. You cannot have point-to-point data forwarded to a central control point; itabsolutely must be locally forwarded, and policy must be enforced locally as well. Switching infrastructure can beupgraded to support dozens of potentially multi-gigabit AP links, but the bottleneck imposed by a central controllerwould be untenable. Therefore the intelligence, policy enforcement, and network services need to be locallyenforced, not centrally.Second is the fact that these high-speed clients are, in fact, mobile. This makes load balancing across theinfrastructure paramount. If you architect a network to forward data to a central control point, as it is in thecontroller-based model, there is no way to balance multiple Gbps of data across the controllers. The architecture’sinherent limitations will leave you with little choice but to re-architect the network and invest large amounts of timeand money. The fact is that even though 802.11ac is in the future, it must be architected for today in order tohandle both mobility and high bandwidth clients.With BYOD a primary factor in networks deployed today there are many important considerations that should bereviewed. 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.Copyright ©2012, Aerohive Networks, Inc. 4
  5. 5. Providing service to the device once it’s onboard: this includes how the devices, which are neither ownednor managed by the IT department, access corporate network services like file sharing, printing, videoconferencing, etc.BYOD is about more than “onboarding” mobile devices. It must include a means to make them useful andproductive members of the corporate community. Once safely and securely on the network, you must considerhow 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 understandhow much comparisons vary depending on feature set. In many cases, this means that the IT should review notonly the cost of the hardware, but the cost of any licenses that are needed to make the WLAN perform asspecified. Cost considerations should also include “soft” costs, such as the cost of operating the solution. Mostenterprises do not have a Wi-Fi expert on staff; in many branches, there is not even an in-house IT staff. WLANmanagement 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 whenconsidering their initial Wi-Fi network. Any Wi-Fi network under consideration today should take into account thefact that the deployment will be required to scale to accommodate more devices, more users, more heavyapplications, and, of course, newer, faster WLAN technology. It is clearly untenable to put in a Wi-Fi solution thatis “maxed out” at 802.11n.Copyright ©2012, Aerohive Networks, Inc. 5
  6. 6. Key RequirementsThere are a number of requirements that must be closely examined when considering a WLAN purchase. AsWi-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 thatis doing “business as usual.” Wireless gear that was included at low or no cost as part of a larger networkingequipment buy was understandable when the WLAN was a convenience-only addition to the wired network. Noenterprise, however, will find this reasoning acceptable as Wi-Fi becomes the primary means of accessingcorporate resources, and the carrier of mission-critical applications.Architectural ConsiderationsThe fundamental architecture of wired networks has probably not been considered by most IT professionals sincethe advent of Fast Ethernet. While there have certainly been advances in how to get the most out of the wirednetwork, the underlying technology is very well understood. This is not the case in wireless networking, wheremany of today’s leading vendors base their implementations upon the usage expectations of legacy conveniencenetworks that were prevalent a decade ago. While Wi-Fi technology has advanced exponentially since 2001, it isimportant to consider whether WLAN vendors have actually changed their architecture to be more seamlesslyintegrated into well-known network architectures (core, distribution, access) and their traffic flows, or if they havean expectation that the network architecture will change to accommodate their WLAN solution.Three PlanesAny consideration of WLAN technology necessarily begins with a brief discussion of the architectures derivedfrom the traffic components themselves, since it is from them that the Wi-Fi network is built. Wireless traffic iscommonly 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). OtherCopyright ©2012, Aerohive Networks, Inc. 6
  7. 7. 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 forwardingCentral Control ModelThe concept of a central controller is derived from a lack of sufficient, affordable processing power to handle bothcontrol and data functions at the AP. According to industry veteran Bob O’Hara, one of the originators of thisarchitecture, “Centralized controllers were never the ‘right’ way to handle control traffic. They were createdbecause that was one of the only ways to handle the problem given the balance between cost and processingpower 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 lessexpensive 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.Copyright ©2012, Aerohive Networks, Inc. 7
  8. 8. 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 ModelStill another type of architecture takes advantage of the exponential increase in processing speed/power and theattendant decrease in cost to put both the data plane and control plane functions on the AP, removing the centralcontroller altogether. The resulting architecture looks more like the Internet, with no central point of failure and acompletely distributed control plane coordinating the communication and exchanging state with advancedprotocols. If a problem occurs, the APs in this model are able to dynamically route around it maintaining full stateand operation. This makes the architecture extremely resilient and flexible, while at the same time making it moreaffordable because there is no additional equipment beyond the APs. Because a WLAN with distributed controland intelligence functions more like a grid computer, it can also act on an extremely high volume of control andpolicy decisions made at the edge of the network without having to forward everything to be processed by aseparate device. This increases overall network performance and enables true QoS.Copyright ©2012, Aerohive Networks, Inc. 8
  9. 9. Architectural ConclusionsThis quick examination of Wi-Fi network architectures highlights several considerations. First, the data plane mustbe distributed. Considering the explosion of high-speed devices and the BYOD phenomenon this is a given in anynetwork. The second is that management must be centralized to enable easy, consistent views of networkoperations for more efficient problem resolution and minimal interruption of service; central management is largelyalso considered a given. The fact that management is centralized, however, does not necessarily imply that itmust be located on premise, in a piece of hardware. Because management traffic is out-of-band, a managementdevice 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 acentral controller, housed in hardware. Newer models have put this central controller into the cloud; it’s importantto realize, however, that unlike management traffic, control plane information must be constant and uninterruptedas it has direct functional impact on the WLAN. Therefore, while a cloud-based controller could lower overallcosts, it can still be a liability to resilience and performance. Some legacy controller vendors have implementeddistributed forwarding, in which traffic is passed directly from AP to AP, without the benefit of control planeinformation. While this model may work in some situations, it falls short in many others where security and QoSfeatures (among others) are essential and require higher level, compute-intensive functions be performed by acentral controller. Finally, some vendors have taken advantage of low-cost processing power to pass controlplane information from AP to AP. This approach enables higher speed clients to be supported, distributesprocessing for increased capacity, future-proofs the network, and provides full functionality without any singlepoint of failure.Copyright ©2012, Aerohive Networks, Inc. 9
  10. 10. 10 Things A WLAN Must DoThe combination of the iEverything explosion with the speed and reliability of 802.11n has created a compellingcase for Wi-Fi as the primary access layer. Unfortunately for the WLAN buyer, there is no longer a singlearchitectural model from which to choose, and legacy vendors may obscure underlying issues as they seek toretain their revenue base. In order to make the right decision for your network, you should consider the followingareas to ensure that the WLAN you choose will satisfy immediate requirements while enabling you to be preparedfor 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 DevicesYour 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) policiesCopyright ©2012, Aerohive Networks, Inc. 10
  11. 11. 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 shouldn’t 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 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 MaintenanceYour WLAN should have a single consistent architecture that scales in both capital andoperational 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.Copyright ©2012, Aerohive Networks, Inc. 11
  12. 12. • 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.CostYour 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.Copyright ©2012, Aerohive Networks, Inc. 12
  13. 13. 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.SecurityYour 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, ActiveCopyright ©2012, Aerohive Networks, Inc. 13
  14. 14. 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 PerformanceYour 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.Copyright ©2012, Aerohive Networks, Inc. 14
  15. 15. • 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.Copyright ©2012, Aerohive Networks, Inc. 15
  16. 16. Using The RFP ProcessTo Select A WLANMost companies will use the RFP as a way to narrow the list of possible WLAN vendors to consider. In the lastsection we overviewed 10 things a WLAN must do. In this section, we’ll show how to use those requirements aspart of an RFP process. The majority of these considerations should be included under the Scope of Worksection, in which the RFP requests a detailed list of the business and technical requirements. This section willgive you a starting point for your WLAN RFP and initial “things to think about” while building your RFP.Overview of Proposed Solution – ArchitectureThis is a good place to ask the vendor to outline the architectural model that they are proposing. This is also anappropriate 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 SpecificationsCapacity and ScalabilityIn this section, look for the number of access points specified for each site under consideration. They should alsocall out the client capacities of each AP/deployment. You may request that the deployment be specified forheadquarters 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.Copyright ©2012, Aerohive Networks, Inc. 16
  17. 17. • Feature Licenses – In many cases, functionality is enabled via license. Are these licenses included with the gear? What if a site is added?Outage ManagementThis section should describe how the system functions in the case of an outage, whether of the outage involves apiece 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) ManagementThis section should call out which protocols are supported as well as what elements of RF management aresupported 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 vendor’s 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.Copyright ©2012, Aerohive Networks, Inc. 17
  18. 18. Power ManagementThis section should describe the features and controls required for power management of the WLAN accesspoints. 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 overWLAN, video conferencing, etc.).SecurityThis section should describe how the WLAN provides security, as well as how it will interact with existing networksecurity specifications. Be sure that responses address any regulatory compliance requirements, includingHIPAA, PCI-DSS and more. Details could include firewalling, Wireless Intrusion Detection (WIDs), networkaccess control, security event management, authentication methodology, identity-based access controls, androgue 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 supportBYOD support is a relatively new requirement, but must be considered for any new Wi-Fi network underconsideration. 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 ConfigurationIn this section, the vendor should specify the steps required to deploy the WLAN. This should include anypreplanning capabilities. In addition to consideration of how to deploy the WLAN at Corporate or HQ, it is vital toconsider: • 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?Copyright ©2012, Aerohive Networks, Inc. 18
  19. 19. Systems ManagementIt is crucial to thoroughly understand the systems management capabilities of any WLAN being considered, sincethis will be the largest ongoing expense of the overall deployment. The vendor should list and clearly describeevery 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 AgreementAs WLAN becomes the primary access layer, it must support rich applications, many of which have strong QoSrequirements. To what degree does the management interface support the separation and prioritization of thistraffic? Is it possible to enable an enforceable SLA with this system? If yes, how does the process function? Is itautomatic, or does it require end user intervention?TroubleshootingWLAN is subject to a variety of issues that are unique to RF. For the WLAN to be useful, it must be easy topinpoint 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?Copyright ©2012, Aerohive Networks, Inc. 19
  20. 20. 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 EMEA Headquarters Aerohive Networks, Inc. Aerohive Networks Europe LTD 330 Gibraltar Drive Sequel House Sunnyvale, California 94089 USA The Hart Phone: 408.510.6100 Surrey, UK GU9 7HW Toll Free: 1.866.918.9918 +44 (0)1252 736590 Fax: 408.510.6199 Fax: +44 (0) 1252711901 www.aerohive.comCopyright ©2012, Aerohive Networks, Inc. 20