AEROHIVE NETWORKS WHITE PAPER New generation WLAN architecture http://www.aerohive.com
NOVEMBER, 2009
Patrice Puichaud –
[email protected] – Tél. : +33.661.994.373
Copyright © 2009, Aerohive Networks, Inc.
CONTENTS Introduction New generation of WLAN architecture Limits of autonomous and controller-based Access Points Trends and opportunities
8 8 8 8
Aerohive Cooperative Control Architecture A complete solution for distributed, mission critical WLAN infrastructures
9 12
Key Aerohive Concepts and Naming Conventions
13
Cooperative Control
14
Cooperative control protocols
14
HiveAP Auto Discovery & Self Organization
14
Cooperative RF control
14
Seamless roaming Autonomous APs do not support seamless roaming Seamless roaming with Aerohive’s HiveAP implementing AMRP Seamless layer 3 roaming
15 15 16 16
Policy Enforcement at the Edge
18
Multiple user profiles
18
QoS Policy Enforcement at the Edge
19
Security Policy Enforcement at the Edge
21
Integrated Intrusion Detection System (Rogue detection and mitigation)
21
Integrated Captive Web Portal
23
Identity-Based Dynamic Network Extension (DNX)
24
Optimizing Network and Client Performance Through Dynamic Airtime Scheduling
25
The problem
25
Mixed Data Rates in Traditional Wireless LANs
25
Aerohive QoS
28
Dynamic Airtime Scheduling Concepts and Examples Single Protocol (802.11a) with Different Data Rate Clients 802.11n Environments
29 29 30
Dynamic Airtime Scheduling in a Nutshell Upstream Traffic and Dynamic Airtime Scheduling Voice over WLAN with Dynamic Airtime Scheduling Giving Preference with Dynamic Airtime Scheduling True Per-Packet Airtime Calculations vs. Protocol Based Scheduling Using Ratios
31 31 31 33 33
Conclusion
34
SLA Compliance: Wireless Fidelity Achieved
35
The problem
35
Wi-Fi That Works A Simple Machine Industry Response To-Date
35 35 36
The Big Picture
36
Aerohive – New generation WLAN architecture
2
Copyright © 2009, Aerohive Networks, Inc.
SLA Compliance – How It Works Performance Sentinel Airtime Boost
37 37 38
SLA Compliance – Making It Happen Configuration
39 40
Conclusion
40
Private PreShared Key
41
The problem Benefits
41 41
Overview of Common Methods for Wi-Fi Access
41
Wi-Fi Access using Aerohive Private PSK
43
Private PSK Deployments Using HiveManager
44
Securing Guest Access with GuestManager and Private PSK
45
Summary
47
Best Path Forwarding
48
Scalable layer 2 routing and optimal path selection
48
Security with Best Path Forwarding
49
Scalability with Best Path Forwarding
49
Wireless Mesh
49
High Availability
50
Distributed architecture for native high availability
50
Automatic re-routing upon network failure
52
Flexible Authentication Methods
53
HiveAP Radius Server
53
Multiples user authentication solutions
53
SmartPOE
54
Central Management with HiveManager
55
Simple and Scalable Management with the HiveManager
55
HiveManager Components and Communication
56
Access profiles
57
Simplified Configuration Management
57
Zero Configuration for Wireless Access Point Deployments
58
Simplified Monitoring and Troubleshooting
58
Reporting
59
HiveManager Online: Less Dollars, More Sense
60
Simpli-Fi A Point of Clarification Elevator Pitch
60 61 61
Easy and Easier
62
Aerohive – New generation WLAN architecture
3
Copyright © 2009, Aerohive Networks, Inc.
Simplification Sweetness Streamlining Support
63 63
Dare to Demo Demo Duo
63 64
Serious Security
64
Gold Lining at Silver Lining Prices Micro Case Studies Less Stuff Means Less Money
65 66 67
Conclusion
67
Conclusion
Aerohive – New generation WLAN architecture
68
4
Copyright © 2009, Aerohive Networks, Inc.
LIST OF FIGURES Figure 1: WLAN applications and productivity evolution
8
Figure 2: Migration of applications to the WLAN infrastructure
8
Figure 3: Aerohive Cooperative Control Architecture
9
Figure 4: Aerohive’s Expanded Network Management Solutions
10
Figure 5: Aerohive’s Network Management Solutions – Start small, seamless upgrade path
10
Figure 6: Virtual HiveManager – Highly flexible management solution for enterprises with multiple operating entities, serviced by single or multiple IT departments
11
Figure 7: Aerohive Secure, Coordinated WLAN infrastructure without Controllers
12
Figure 8: Aerohive Networks Naming Conventions
13
Figure 9: Managing frequencies and channel in the 2.4 GHz band
15
Figure 10: Autonomous APs – No Seamless Roaming in Secure Wireless LANs
15
Figure 11: HiveAPs – Authentication, Key Derivation, and Key Distribution
16
Figure 12: Roaming cache on a HiveAP
17
Figure 13: The Process for Seamless Layer 3 Roaming
17
Figure 14: Identity and Location-Based Policy
18
Figure 15: QoS Policy Enforcement at the Edge
19
Figure 16: Rogue APs
22
Figure 17: Rogue AP Location on Topology Map
22
Figure 18: Rogue Mitigation
22
Figure 19: Embedded Captive Web Portal
23
Figure 20: A Common Use for Identity-Based DNX: Placing Guests in a Firewall DMZ
24
Figure 21: Frames over time based on standard Wi-Fi behavior
26
Figure 22: Frames over time based on equal airtime
26
Figure 23: Two simulated file transfers, one from a client connected at 54Mbps, and the other from a client connected at 6Mbps 27 Figure 24: Comparison of simultaneous transmissions of 10,000 1,500 byte HTTP frames to simulate a file downloaded by a low speed client and a high speed client 27 Figure 25: Comparison of simultaneous transmissions of 10,000 1,500 byte HTTP frames to simulate a file downloaded by a low speed client and a high speed client with Aerohive’s Dynamic Airtime Scheduling 28 Figure 26: Three simultaneous file transfers, one test without and one test with Dynamic Airtime Scheduling
30
Figure 27: Dynamic Airtime Scheduling in 802.11 environments
30
Figure 28: Eight clients downloading files connected at different data rates (shown) while twenty other clients are simultaneously on voice over WLAN calls with toll quality (not shown) 32 Figure 29: Example of twenty simulated SIP voice calls getting toll quality running concurrently with the eight simulated file transfers shown previously 32 Figure 30: Airtime preference given to employees vs. guests; Both the above graphs are from a single test run, it is shown as two separate graphs for simplicity given the number clients involved 33 Figure 31: Protocol-based scheduling with different speed clients of the same protocol
34
Figure 32: The Progression from Convenience to Fidelity
36
Aerohive – New generation WLAN architecture
5
Copyright © 2009, Aerohive Networks, Inc.
Figure 33: Network Visibility (APs & Clients) – The Dashboard
37
Figure 34: Airtime Boost Functionality
38
Figure 35: Airtime Boost: Building on Dynamic Airtime Scheduling
38
Figure 36: Drilling Down Into Client Sessions
39
Figure 37: Example 1
39
Figure 38: Figure 2
39
Figure 39: SLA Configuration in HiveManager’s User Profile
40
Figure 40: SSID with Preshared Key vs. SSID with Private PSK
43
Figure 41: HiveManager Configuration and Private PSK Generation and Distribution
44
Figure 42: Emailing Private PSKs to Users
45
Figure 43: Revoking Private PSKs
45
Figure 44: GuestManager Operation with Private PSK
46
Figure 45: Lobby Administrator Creates Guest Account
46
Figure 46: Centralized vs. Distributed Data Forwarding
48
Figure 47: HiveAPs Configured within a Wireless Mesh
49
Figure 48: Controller failing and affecting every access points
50
Figure 49: Self-Healing Resilience with Dynamic Mesh Failover
50
Figure 50: Reducing risk with wired-like resilience
51
Figure 51: High Availability with Seamless Roaming and Automatic Rerouting
52
Figure 52: Multiple user authentication methods
53
Figure 53: Different views of HiveManager Topology
55
Figure 54: HiveManager Components and Communication with HiveAPs
56
Figure 55: Granular access profiles for HiveManager administrators
57
Figure 56: HiveManager Dashboard
58
Figure 57: HiveManager Real-time Active Clients Display
59
Figure 58: HiveManager Online (HMOL) is the Simplest Instantiation of Enterprise Wi-Fi
60
Figure 59: HiveManager Online Enterprise (HMOL Enterprise)
62
Figure 60: HiveManager Online Express
62
Figure 61: The Distributed Enterprise with HiveManager Online (HMOL)
63
Figure 62: CAPWAP secured with DTLS
64
Figure 63: Group or Individual Administrative Permissions
65
Figure 64: Controllers cause stair-stepped cost
65
Figure 65: For Those Who Like Pictures
66
Aerohive – New generation WLAN architecture
6
Copyright © 2009, Aerohive Networks, Inc.
LIST OF TABLES Table 1: Aerohive 802.11n Access Points (HiveAP100 and 300 series)
9
Table 2: PSK versus PPSK versus 802.1X
44
Table 3: Aerohive eases the migration to .11n with Smart PoE, Link Aggregation & Resiliency
54
Table 4: WLAN Component Comparison Chart
67
Aerohive – New generation WLAN architecture
7
Copyright © 2009, Aerohive Networks, Inc.
INTRODUCTION New generation of WLAN architecture Limits of autonomous and controller-based Access Points The first wave of wireless LANs were autonomous (standalone or fat) access points and were relatively simple to deploy but lacked the manageability, mobility, and security features that enterprises required, even for convenience networks. The lack of manageability and control increased the operational costs of these WLANs. The time associated with carrying out pre installation site surveys, AP location tuning, periodic post-installation surveys and the per-AP configuration and image updating drove organizations to look for alternative solutions. Central controller-based architectures emerged to address these issues and were able to add central management, allow device roaming, and provide a coordinated RF management and security policy to these networks. Unfortunately, they also introduced opaque overlay networks, performance bottlenecks, and single points of failure, increased latency and substantially higher costs to enterprise networks. While being able to reduce the WLAN management costs, most controller-based solutions will approach 2 times to 4 times the capital cost of a traditional autonomous AP deployment, especially when the environment is mission critical and the need for distributed or redundant controllers is factored in to the equation. Aerohive has developed a solution that provides for a single wireless architecture that meets the technology and business requirements of both convenience and mission-critical network applications. It is a single wireless architecture that is cost-effective for the smallest branch office, yet meets the availability and manageability requirements of a campus or warehouse deployment. Trends and opportunities Wireless LAN applications are evolving very quickly from initial proprietary applications and convenience application to business and mission critical applications. These new applications require a high performance, resilient, scalable and affordable WLAN infrastructure.
Figure 1: WLAN applications and productivity evolution
The WLAN infrastructure is evolving from a convenience network for basic applications (Web, Email), coverage of meeting rooms to the primary access network, coverage of the entire enterprise, security and mission critical applications (voice, multimedia, asset tracking, business mobility applications).
Figure 2: Migration of applications to the WLAN infrastructure
Aerohive – New generation WLAN architecture
8
Copyright © 2009, Aerohive Networks, Inc.
Aerohive Cooperative Control Architecture Aerohive has introduced an innovative new class of wireless infrastructure equipment called a Cooperative Control Access Point (CC-AP). A CC-AP combines an Enterprise-class access point with a suite of cooperative control protocols and functions to provide all of the benefits of a controllerbased WLAN solution, without requiring a controller or an overlay network. Aerohive’s implementation of a CC-AP is called a HiveAP access point. This cooperative control functionality enables multiple HiveAPs to be organized into groups, called “hives,” that share control information between HiveAPs to enable functions like fast layer 2/layer 3 roaming, coordinated RF management, security, quality-of-service (QoS), mesh networking, load balancing and high availability. This capability enables a next generation wireless LAN architecture, called a cooperative control wireless LAN architecture, that provides all of the benefits of a controllerbased architecture, but is easier to deploy and expand, lower cost, more reliable, more scalable, more ubiquitously deployable, higher performing and more suitable for voice-overwireless LAN than today’s controller-based architectures. Centralized configuration, monitoring and reporting is provided by a central network management system, called the HiveManager. This management appliance can be located anywhere within the network and is not essential to the networks ongoing operation.
Figure 3: Aerohive Cooperative Control Architecture
To create the cooperative control architecture, Aerohive has developed two lines of products: -
Cooperative control access point, HiveAP: o Dual radios to support simultaneous use of IEEE 802.11(n)b/g in addition to IEEE 802.11(n)a for wireless access and wireless mesh connectivity. o A set of cooperative control protocols to provide dynamic MAC-based routing, automatic radio channel selection and fast roaming. o A centralized management appliance for simplified configuration, updating, monitoring and troubleshooting tasks. o Robust security with IEEE 802.1X , the latest IEEE 802.11i standards, firewall rules, layer 2 through layer 4 denial-of-service (DoS) prevention, advanced quality of service mechanisms (802.11e and WMM), IPSec VPN,…
Table 1: Aerohive 802.11n Access Points (HiveAP100 and 300 series)
Copyright © 2009, Aerohive Networks, Inc.
-
A central network management platform, HiveManager: central management solution to remotely manage and monitor 1000’s of HiveAP’s with admin delegation.
Figure 4: Aerohive’s Expanded Network Management Solutions Aerohive Network Management Solutions provide different products to manage and monitor one or multiple WLAN architectures based on the size of the deployment and the IT sophistication, with seamless upgrade from one to another, as showed in the figure hereafter.
Figure 5: Aerohive’s Network Management Solutions – Start small, seamless upgrade path
Aerohive – New generation WLAN architecture
10
Copyright © 2009, Aerohive Networks, Inc.
-
Role-based administration and policy-based configuration with Virtual HiveManager: Aerohive has introduced unique virtualization capabilities for its HiveManager Network Management System with support for multiple, single HiveManager instances on a single appliance/server with complete separation of administration, views and reporting, allowing enterprises to delegate portions of the WLAN network to subsidiaries or franchises and enabling managed WLAN services to SMB customers.
Figure 6: Virtual HiveManager – Highly flexible management solution for enterprises with multiple operating entities, serviced by single or multiple IT departments Virtual HiveManager helps large enterprises with multiple operating companies or distributed IT functions to separate administrative interfaces. Virtual HiveManager enables resellers and service providers’ opportunities to build service revenues Aerohive’s unique WLAN architecture relies on three mains components, tightly integrated together: -
Cooperative control: a set of protocols providing functions such as mobility, RF control, scalability and resiliency that are essential for wireless networks.
-
Best path forwarding: a key technology in Aerohive Networks’ cooperative control architecture that allows HiveAPs to cooperate with neighboring HiveAPs to support distributed data forwarding functions such as layer 2 routing, optimal path selection and high availability.
-
Policy enforcement at the edge: another key technology in Aerohive Networks’ cooperative control architecture that allows HiveAPs to enforce powerful and flexible identity-based security, access control and QoS policies at the edge of the network.
Aerohive – New generation WLAN architecture
11
Copyright © 2009, Aerohive Networks, Inc.
A complete solution for distributed, mission critical WLAN infrastructures Aerohive’s line of products includes all the necessary components for a complete, secure and distributed WLAN infrastructure for the entire enterprise: -
HiveAP access points: indoor, industrial, outdoor access points.
-
Central Network Management Solution : to remotely and securely manage and monitor 1000’s of HiveAP’s with admin delegation.
-
Additional components for advanced WLAN features: o GuestManager: guest management solution with simple WebUI for creating and managing visitors accounts. o Authentication and access control partnering with Microsoft, Cisco, and Juniper. o Location tracking (people, devices) with RFID/Wi-Fi tags from Aeroscout or Ekahau. o Site survey with Airmagnet or Ekahau. o Wireless Intrusion Detection with Airtight. o Bar code readers, VoIP phones,…
-
Certifications from international standardisation organisations (Wi-Fi Alliance, PCI, CWNP,…).
The figure hereafter shows the global Aerohive WLAN architecture in a distributed network environment.
Figure 7: Aerohive Secure, Coordinated WLAN infrastructure without Controllers
Aerohive – New generation WLAN architecture
12
Copyright © 2009, Aerohive Networks, Inc.
Key Aerohive Concepts and Naming Conventions The diagram below shows that HiveAPs have different roles which are automatically designated based on how they are connected to the network.
Figure 8: Aerohive Networks Naming Conventions The following is a list of key terms used to describe the Aerohive Networks cooperative control architecture: TM
-
HiveAP : the product brand name for Aerohive’s CC-AP (Cooperative Control Access Point). HiveAPs coordinate with each other using cooperative control protocols to provide critical functions including seamless mobility, automatic RF control and best path forwarding.
-
HiveOS : the operating system developed by Aerohive Networks that runs on HiveAPs.
-
HiveManagerTM WLAN NMS: a complete network management solution that enables simple configuration, OS updates, and monitoring of HiveAPs within a cooperative control wireless LAN architecture.
-
Hive: a grouping of HiveAPs that are connected within the same layer 2 broadcast domain or VLAN. HiveAPs are grouped into hives to provide fast propagation of routes and roaming caches between the HiveAPs, aid in the calculations used by ACSP for automatic RF control, and limit the propagation of broadcasts throughout a wireless mesh.
-
Wired Uplink: Ethernet connections from a HiveAP to the wired network, which is typically called the distribution system (DS) in wireless standards, used to bridge traffic to and from the wireless and wired LANs.
-
Wireless Uplink: wireless connections between HiveAPs used to create a wireless mesh and provide wireless connections to transport control and data traffic.
-
Wireless Access Link: the wireless connection between a wireless client and a HiveAP.
-
Portal: a HiveAP that has connections to both the wired and wireless LANs and provides default routes to mesh points within the Hive.
-
Mesh Point: a HiveAP that is connected to the hive via wireless uplinks and does not use a wired uplink.
-
Cooperative Control Signaling: the communication between HiveAPs using Cooperative Protocols.
TM
Aerohive – New generation WLAN architecture
13
Copyright © 2009, Aerohive Networks, Inc.
COOPERATIVE CONTROL Utilizing cooperative control – a key technology in Aerohive Networks’ cooperative control architecture – HiveAPs in cooperation with neighboring HiveAPs are able to support control functions such as dynamic RF management, layer 2/layer 3 roaming, client load balancing, wireless mesh networking and thus eliminating the need for a centralized controller.
Cooperative control protocols HiveAPs in a Hive cooperate with each other using Aerohive’s cooperative control protocols: AMRP (Aerohive Mobility Routing Protocol) -
AMRP (Aerohive Mobility Routing Protocol) : for seamless layer 2 roaming, mesh routing and redundancy.
-
DNXP (Dynamic Network Extensions Protocol): for seamless layer 3 roaming.
-
INXP (Identity-Based Network Extensions Protocol): allows clients to be tunneled to selected HiveAPs based on their login credentials or SSID.
-
ACSP (Automatic Channel Selection & Power): allows the HiveAPs to dynamically select radio channels and radio power settings for wireless mesh and access radios.
HiveAP Auto Discovery & Self Organization HiveAPs have the ability to discover each other whether they are connected to each other over a wired network, or wirelessly. When HiveAPs are powered on, they start to probe for both wired and wireless neighbors, and if neighbors are found with the same hive or mobility credentials, they can build secure connections to each other over wired uplinks with AES, and wireless uplinks with using WPA with AES-CCMP. Once the neighbor relationships have been established between HiveAPs using wired and wireless uplinks, HiveAPs within a hive use cooperative control protocols to provide seamless mobility, automatic RF control, and resiliency. If HiveAPs locate neighboring HiveAPs that are in a different subnet or are configured within different hives, as long as the HiveAPs are configured with same global mobility security settings, they will exchange IP information with each other and establish communications over the routed network infrastructure to provide cooperative control functionality across layer 3 boundaries.
Cooperative RF control In order to eliminate interference from the same or adjacent radio channels, HiveAPs use Aerohive Channel Selection Protocol (ACSP) to cooperate with each other to automatically select best radio channels on which the radios operate. This ensures the most effective use of radio channels for optional wireless network performance. HiveAPs use ACSP to scan radio channels and build tables of discovered wireless devices. These tables are used to identify and classify interference. HiveAPs communicate ACSP state information with each other and use this information to select the appropriate channels depending on the wireless network topology and configuration. If both radios are being used for wireless access, then ACSP will select channels for each HiveAP that minimize interference with their neighbors. This is accomplished by ensuring that they use different channels than their immediate neighbors, and that they minimize co-channel interference with other more distant HiveAPs.
Aerohive – New generation WLAN architecture
14
Copyright © 2009, Aerohive Networks, Inc.
If the HiveAPs are using wireless uplinks for wireless mesh connectivity, ACSP ensures that that they use the same channel between HiveAPs for these links, while still minimizing interference for the access links. To maintain optimal wireless LAN performance, ACSP constantly monitors the state of the radio channels to look for interference. If an interfering device arrives within range of the current operating radio channel, ACSP has the ability to trigger the move to a new channel. Additionally, administrators have the option to permit radio channel changes only if no stations are associated, preventing clients from being disconnected due to those changes.
Figure 9: Managing frequencies and channel in the 2.4 GHz band
Seamless roaming Fast roaming functionality is provided by AMRP, which predictively and securely distributes client state and encryption key information, allowing wireless clients to seamlessly roam between HiveAPs, while maintaining authentication state, firewall access rights and QoS enforcement settings, without losing sessions. Autonomous APs do not support seamless roaming With traditional autonomous APs that exist without knowledge of each other, seamless roaming within a secure wireless LAN using IEEE 802.1X and EAP for secure authentication is not possible. This is because during authentication, the RADIUS server, wireless client, and AP exchange information and derive encryption keys between themselves.
Figure 10: Autonomous APs – No Seamless Roaming in Secure Wireless LANs
If the wireless client moves to another AP, it does not have any of the keys that exist on the previous AP and the wireless client will have to repeat the entire authentication and key derivation process again. During this process, existing sessions on the client that are time sensitive will be terminated, such as voice or file transfers.
Copyright © 2009, Aerohive Networks, Inc.
Seamless roaming with Aerohive’s HiveAP implementing AMRP Aerohive Networks has solved the problem that exists with autonomous AP solutions using AMRP. Whether connected via the wired LAN or wireless LAN mesh, HiveAPs cooperate with each other using AMRP to predictively exchange identity, and key information to neighboring HiveAPs as described in the diagram below. Step 1: After a wireless client successfully authenticates with a RADIUS server using 802.1X EAP authentication, the information exchanged between the RADIUS server and the client is used to derive a key called the pairwise master key (PMK). This PMK is the same on the wireless client and RADIUS server. Step 2: In order for the HiveAP and the client to have encrypted communication between each other, the RADIUS server transfers the PMK to the HiveAP so that the client and HiveAP can generate keys derived from the PMK for secure wireless communication between them.
Figure 11: HiveAPs – Authentication, Key Derivation, and Key Distribution
Step 3: The HiveAP distributes the PMK and identity information to all neighboring HiveAPs to ensure that if the client roams to a neighboring HiveAP, the authentication and key exchange does not need to be repeated, allowing for extremely fast roaming times.
Note: for security reasons, this information is communicated over encrypted links, and HiveAPs only store the PMK and any other keys derived by the client and HiveAP in memory – not even administrators can view them. Also, the keys are removed from the system along with all user identity when a HiveAP is powered off. This prevents any security breaches from occurring even if the wired network is sniffed or if a HiveAP was ever compromised. Along with the key information that is distributed amongst neighboring HiveAPs, AMRP also distributes identity information such as the user profile and VLAN IDs associated with the users. This enables the HiveAPs to enforce the identity-based firewall access policies and QoS settings as the user roams between HiveAPs. Seamless layer 3 roaming Mobility in an IP network is challenging because as you move from subnet to subnet the IP settings change. To allow users to maintain their IP settings and network connections while roaming across subnets throughout a wireless LAN, Aerohive Networks has developed the Dynamic Network Extension Protocol (DNXP). DNXP provides the ability to manually set or automatically elect HiveAPs within a subnet responsible for facilitating the dynamic creation of tunneled paths between HiveAPs within different subnets. Essentially, DNXP provides tunneled extensions between networks that work in conjunction with AMRP to exchange identity and key information permitting clients to seamlessly roam between subnets while preserving IP address settings, client session state, firewall access rights and QoS enforcement settings. This is especially important for clients using VoWLAN (Voice over WLAN) applications. In order to provide layer 3 roaming capabilities with DNXP, HiveAPs that are within different subnets can be discovered automatically by probing radio channels, or they can be manually configured with knowledge of HiveAPs in different subnets. If DNXP is enabled, and HiveAPs within different subnets utilize the same hive mobility credentials, then HiveAPs will establish tunnels between neighboring HiveAPs that are in different subnets. With the underlying tunneled network infrastructure in place, when clients roam to a HiveAP that borders a HiveAP within a different subnet, AMRP can be used to distribute identity and key information to the neighboring HiveAPs just as if they were on the network.
Copyright © 2009, Aerohive Networks, Inc.
Furthermore, the tunneled paths are selected through the best path available via the wired or wireless LAN to ensure the least amount of latency.
Figure 12: Roaming cache on a HiveAP Layer 3 roaming process is divided into 3 main steps, described in the diagram hereafter: -
Step 1: the client performs seamless L2 roaming within subnet A.
-
Step 2: after the client successfully roams to HiveAP 2, the GRE tunnel over the Ethernet is used by AMRP to predictively forward identity and key information to HiveAP 3.
-
Step 3: when the client roams to HiveAP 3, the identity and key information is already there and with knowledge that the client is from subnet A, the client’s traffic is tunneled in GRE over the LAN to a designated HiveAP in subnet A. Predictively, HiveAP 3 forwards the wireless client’s information to HiveAP 4 in anticipation of any further roaming.
Figure 13: The Process for Seamless Layer 3 Roaming The layer 3 roaming functionality allows for optimized performance after a roam. For example, if the wireless client that has active sessions roams to a HiveAP in a different subnet, the HiveAP preserves the IP address while the client’s sessions are active, but may optionally be configured to force clients to obtain a local IP address once all the active sessions have timed out. This allows each client to perform optimized local forwarding on the new subnet to which they have roamed. In summary, with HiveAPs and cooperative control, wireless clients can securely and seamlessly roam between HiveAPs within the same or different subnets without impacting client data or voice connections.
Aerohive – New generation WLAN architecture
17
Copyright © 2009, Aerohive Networks, Inc.
POLICY ENFORCEMENT AT THE EDGE Utilizing Policy Enforcement at the Edge, a key technology in Aerohive Networks’ cooperative control architecture, HiveAPs can enforce powerful and flexible identity-based security, access control and QoS policies at the edge of the network: - Applying those policies to the traffic at the local HiveAP allows the QoS engines to instantaneously respond to the real-time variations in wireless throughput inherent to a dynamic RF environment. - Enforcing QoS, access control, and security policies at the HiveAP also allows traffic to be controlled right when it enters the network, rather than after the traffic has traversed multiple hops to reach a central controller.
Multiple user profiles The Aerohive WLAN solution defines different sets of access policies for different classes of users through the creation of user profiles. Each user profile defines a VLAN, QoS policy, MAC firewall policy, IP firewall policy, layer 3 roaming policy and Schedule which is assigned to users when they connect to the wireless LAN. On a HiveAP, one or more user profile attributes are assigned to a single user profile. If a user authenticates with the HiveAP using 802.1X or Authenticated Guest Access the RADIUS server (or Guest Manager) can return a user profile attribute to the HiveAP, which binds the user to a user profile. The user profile attribute returned by RADIUS can be defined based on the user’s group settings in Active Directory, LDAP, or a RADIUS realm. If the system is configured to use PPSK (discussed in section 4.6.7) the user attribute can be assigned based on the unique key or key group. If the user does not use 802.1X authentication, the user profile can be assigned to the user based on the SSID’s default user profile attribute setting The user profile attribute assigned to a user stays with the user as they roam throughout the wireless LAN. Administrators can configure HiveAPs to use the same set of policies for user profiles throughout a WLAN, or they can make refinements based on a location. For example, HiveAPs in one location may specify that user profile that has a QoS policy to provide unrestricted use of bandwidth. However, in another location, a HiveAP may specify that the same user profile defines policies to rate limit all traffic. As the user roams between the two locations, his user profile attribute remains the same, but their policy dynamically changes based on the user profile settings within the HiveAPs at each location. An example of how user profiles are used is shown in the following diagram.
Figure 14: Identity and Location-Based Policy
Aerohive – New generation WLAN architecture
18
Copyright © 2009, Aerohive Networks, Inc.
In this example, when a user authenticates with SSID Corp_WiFi, the RADIUS server returns the user profile attribute ute number for that specific user and the HiveAP uses that value to bind that user to a user profile, ensuring the appropriate policies are enforced for that user. This mapping of user profile attribute numbers into specific user profiles can be different in different parts of the network, allowing for either global user policy enforcement or location-specific location specific user policy enforcement. In this case, in some locations a user is assigned different VLANs and QoS policies, but the same firewall policy and layer 3 roaming policies. Likewise, other users assigned to different user profile attributes may follow the same path, but can be assigned to different VLANs and policies. This allows administrators to create access policies based on identity and location. The screen shot below shows the simple configuration element for this powerful feature.
QoS Policy Enforcement at the Edge With wireless technology on its way to becoming the primary form of network connectivity, effective quality-of-service is essential for prioritizing the transmission of traffic onto a wireless network. Aerohive Networks has implemented more effective and robust QoS functionality on HiveAPs to extend the functionality of WMM (WiFi Multi-Media), Multi Media), which is a WiFi Alliance extension to the IEEE 802.11e QoS standard. The main issue is that WMM by itself does not provide all the mechanisms necessary to provide highly effective quality of service within a wireless network. With WMM, traffic from a wireless AP can be prioritized for transmission on to the wireless network. This allows traffic to be classified into four access categories, which are queued and prioritized based on time sensitivity of the data. Higher priority access categories can use a smaller inter inter-frame space and random back-off window ndow to allow transmission to the wireless medium with less delay. In addition to WMM, Aerohive has created advanced classification, queuing, and packet scheduling mechanisms within each HiveAP to allow more granular and deterministic transmission of pack packets into the WMM queues. HiveAPs do this with a sophisticated QoS packet scheduling engine that closely watches the availability of the WMM queues and only transmits to them when they are available, preventing dropped packets and jitter which would otherwise otherwise adversely affect voice quality. Once the packets reach the WMM queues they are transmitted to the wireless medium based on the priority of their access category and the WMM standard transmission mechanisms. The following diagram and steps explain the workflow workflow of the QoS engines within a HiveAPs.
Figure 15: 15 QoS Policy Enforcement at the Edge
Copyright © 2009, Aerohive Networks, Inc.
From wireless: -
Step 1: upon successful authentication with the HiveAP, wireless clients are assigned to a user profile based on default SSID assignment or RADIUS attribute, where QoS policy is assigned.
-
Step 2: as packets from the wireless client enter the HiveAP, the QoS packet classifier categorizes traffic into eight queues per user based on classifier policies that can map traffic to queues based on MAC OUI (Organization Unique Identifier), network service, SSID and interface, or priority markings on incoming packets using IEEE 802.11e or DiffServ.
-
Step 3: the QoS traffic policer can then enforce QoS policy by performing rate limiting and marking. Traffic can be rate limited per user profile, per user, and per queue. Traffic can be marked with IEEE 802.1p or DiffServ so that it can be prioritized through the Ethernet network.
-
Step 4: the QoS packet scheduling engine uses strict priority and weighted round robin techniques to granularly prioritize traffic from each of the eight queues per user for transmission to the Ethernet network. Each queue can also be rate limited to prevent overuse.
To Wireless: -
Step 5: as packets arrive from an Ethernet uplink, a wireless uplink, or an access connection, the traffic is assigned to its appropriate user profile , which defines the QoS policy.
-
Step 6: the QoS packet classifier categorizes traffic into eight queues per user based on QoS classification policies that can map traffic to queues based on MAC OUI (Organization Unique Identifier), network service, SSID and interface, or priority markings on incoming packets using IEEE 802.1p or DiffServ.
-
Step 7: the QoS traffic policer can then enforce QoS policy by performing rate limiting and marking. Traffic can be rate limited per user profile, per user, and per queue. Traffic can be marked with IEEE 802.1e or DiffServ so they can be prioritized through the wireless LAN.
-
Step 8: wireless signal to noise ratios (SNR) vary within milliseconds causing instantaneous changes in bandwidth and error levels. This makes it essential that QoS is performed at the AP to ensure immediate reaction to these changes.
-
Step 9: for efficient transmission of packets on to the wireless network, either for wireless access connections to clients or wireless uplink connections to other HiveAPs, the QoS packet scheduling engine uses strict priority and weighted round robin techniques to granularly schedule traffic from each of the eight queues per user into four WMM hardware queues. Because the QoS packet scheduling engine is on the HiveAPs, it has the ability to closely monitor the availability of the WMM queues and instantaneously react to changing network conditions. The QoS packet scheduling engine only transmits to WMM queues when they are available. This prevents dropped packets and jitter which adversely affect timesensitive applications such as voice.
-
Step 10: WMM transmits packets from the four access categorized based on the available of the wireless medium. Packets from higher priority access categories are transmitted with a smaller inter-frame space and random back-off window to allow transmission to wireless medium with less delay.
Aerohive – New generation WLAN architecture
20
Copyright © 2009, Aerohive Networks, Inc.
Security Policy Enforcement at the Edge With the cooperative control wireless LAN architecture, security policy including MAC address filters, DoS prevention, and firewall rules are enforced at the HiveAP preventing unwanted traffic from accessing the wireless and internal network. Additionally, because HiveAPs are installed at the access layer, wireless traffic from the APs can be forwarded in line with wired traffic and can use the same corporate security systems that are used for wired access such as firewalls, antivirus gateways, intrusion detection and prevention systems, and network access control (NAC) devices. Though wireless clients associated with HiveAPs have the ability to use the same security devices as wired clients, HiveAPs offer additional levels of security targeted specifically for wireless networks. HiveAPs have the ability to set MAC filters per interface that are used as the first level of defense to permit or deny devices from accessing the wireless or wired network through the HiveAP. MAC filters are primarily used to deny rogue APs, deny known unauthorized devices, or permit specific sets of devices such as IP phones based on their MAC OUI. The next level of protection is used to prevent layer 2 DoS attacks that can be used to flood wireless networks with wireless management frames, such as probe requests and responses, association request and responses, and the like. The threshold settings for layer 2 DoS attacks can be configured at per station and per SSID levels. Moving up the layers of the OSI model, the prevention for common yet devastating layer 3 and layer 4 DoS attacks such as UDP and ICMP floods, SYN floods, address sweeps and the like can also be configured at a per station and per SSID level. HiveAPs go beyond counting frames to prevent UDP and ICMP flood attacks. In a wireless network, percent of airtime usage is a far more effective limiting factor than using packets per second. This is because that in a wireless network, depending on the transmission rate, a flood of packets occurs quickly when the wireless connection is at 54 Mbps, and a minimal amount of air time might be used. However, the same amount of packets at a lower transmission rate of 6 Mbps would consume far more air time and the flood attack would cause more harm. Therefore for UDP and ICMP flood attacks, HiveAPs allow the configuration of flood thresholds prevention using percentage of air time. Though firewall protection for wireless clients will occur by the corporate firewalls, HiveAPs provide firewall access control lists to permit or deny traffic based on IP addresses or networks, IP protocols and network services. Using the Aerohive Networks HiveManager NMS centralized management solution, it’s a simple task to apply the security policy settings across an entire network of HiveAPs.
Integrated Intrusion Detection System (Rogue detection and mitigation) The Aerohive solution provides a fully integrated IDS/IPS solution and does not require additional APs or sensors. Using wireless IDS functionality, the each HiveAP has the ability to perform off-channel scanning to locate rogue AP and ad-hoc rogue clients and report them to HiveManager. Administrators can configure rogue AP detection policies that look for APs that do not have valid BSSIDs, SSIDs, authentication and encryption settings, and other more fine tuned settings such as support for short preambles, WMM support and short beacon times. Along with searching for rogue APs via the air, HiveAPs can use in-network rogue AP detection functionality to probe VLANs on the switched network to detect if the rogue APs are physically attached to the corporate switched network. HiveManager can then help the administrator locate the rogue APs so they can be removed.
Aerohive – New generation WLAN architecture
21
Copyright © 2009, Aerohive Networks, Inc.
The picture below shows a list of rogue APs in HiveManager. By selecting a rogue AP in the list, you can view the signal strengths from each HiveAP along with the WIDS policy that was matched to identify the AP as a rogue. In this example a rogue AP with MAC “001977005C90” has been found and was reported by 5 HiveAPs in the vicinity.
Figure 16: Rogue APs Once the rogue APs have been identified, the administrator can go to the topology map where the reporting HiveAPs are located and select the Rogue APs option to display the location of the rogue APs. The following picture shows en example of a discovered rogue APs on the topology map as well as the channel mappings of HiveAPs. The rogue AP is highlighted in the circle.
Figure 17: Rogue AP Location on Topology Map The Aerohive solution has the capability of containing Rogue APs. Rouge AP containment is achieved by an Aerohive AP spoofing the MAC address of the Rogue AP and transmitting a broadcast deauthentication message, this stops any client from associating with the device.
Figure 18: Rogue Mitigation
Aerohive – New generation WLAN architecture
22
Copyright © 2009, Aerohive Networks, Inc.
Integrated Captive Web Portal Another way to apply security at the edge of the network is to use a captive web portal. A captive web portal provides registered users with network access while containing unregistered users. It requires users to perform a task, such as authenticating or registering themselves, before assigning them user profile settings and network settings that allow access to the network beyond the HiveAP with which they are associated. While controller-based solutions usually host the captive web portal (CWP) on the controller itself, Aerohive’s distributed architecture implements CWP directly on the access points, in a distribution fashion (e.g.: the load will be shared between all the access points, and H.A. of the CWP is ensured by deploying multiple access points).
Figure 19: Embedded Captive Web Portal Many options are available for a CWP associated to a SSID: -
Self-registration: require users to accept a network use policy, fill in the various fields in a form, and submit it.
-
Usage Policy Acceptance: for users to accept a network use policy without having to fill in a form.
-
User Authentication: require users to enter and submit a valid user name and password to log in. Choose Both (Auth/Self-reg) to combine the previous two registration types. Users can authenticate themselves by submitting a user name and password or complete and submit a registration form.
WLAN administrators can manually customize their Captive Web Portal pages or use the autogenerated CWP on the HiveAP. HiveManager also provides a convenient way to set up the web pages for a captive web portal and to customize the pages.
Aerohive – New generation WLAN architecture
23
Copyright © 2009, Aerohive Networks, Inc.
Identity-Based Dynamic Network Extension (DNX) The same technology that gives HiveAPs the ability to perform layer 3 roaming can also be used to tunnel wireless clients to a HiveAP in a different network based on their identity. During the authentication process, wireless clients are assigned a user profile by a RADIUS attribute returned after successful authentication, or from the default user profile assigned to a SSID. User profiles, used to define firewall, DoS settings, QoS settings, and VLANs to clients, can also be used to define DNX settings. By configuring DNX parameters within a user profile, authenticated users are tunneled over GRE to a specified HiveAP within a remote network. This way, after a client is authenticated, the client receives its IP settings from a remote DHCP server as if it were physically on the remote network, the security and QoS policies are enforced at the local HiveAP, and the client’s traffic is bridged through a GRE tunnel through the network to a HiveAP at the remote destination. The client is essentially an extended member of the remote network. For example, a team of consultants, contractors or auditors might have a temporary on-site command center or office within a company. Using DNX these temporary clients can associate with any HiveAP within a network and have their traffic tunneled directly to a HiveAP within their command center as if they were local.
Figure 20: A Common Use for Identity-Based DNX: Placing Guests in a Firewall DMZ In the diagram above a Guest SSID is set up on HiveAPs within the internal network configured with a user profile that tunnels all guest traffic to a HiveAP behind the firewall in the DMZ. When a guest associates with the Guest SSID, a captive portal is used to gather information about guest users and requires them to agree to an acceptable Internet usage policy. The information is then logged, the security and QoS policies are enforced, and the permitted guest traffic is tunneled to the HiveAP in the DMZ for direct Internet access. At no time can the guest user access the internal secured network. Alternatively, or additionally, guest traffic can be mapped into a Guest VLAN for isolated backhaul to the DMZ or Internet gateway.
Aerohive – New generation WLAN architecture
24
Copyright © 2009, Aerohive Networks, Inc.
OPTIMIZING NETWORK AND CLIENT PERFORMANCE THROUGH DYNAMIC AIRTIME SCHEDULING The problem In wireless LANs one thing is certain, wireless performance is often not as advertised. Wireless is a shared medium, meaning that all clients and neighboring APs compete for the same limited bandwidth, in addition, each client’s speed varies depending on the protocol it is running (802.11 a/b/g/n) and the signal strength, interference and noise it is experiencing. Older clients using lower speed protocols, interference, inconsistent RF coverage and clients connecting at the fringe of the network or moving behind obstructions all lead to low data rate connections. These slow clients consume more airtime to transfer a given amount of data, leaving less airtime for other clients, decreasing network capacity and significantly degrading the performance of all clients on the network. This paper reviews key issues that affect wireless LAN performance, and shows how a new patent pending wireless Quality of Service (QoS) technology from Aerohive Networks – Dynamic Airtime Scheduling— can solve these problems. The benefits of Dynamic Airtime Scheduling are compelling to both the IT organization and to the users of the wireless LAN. It enables clients connected at higher data rates in a mixed data rate environment to achieve up to 10 times more throughput than they would get with traditional wireless LAN infrastructures - without penalizing lower speed clients. This means that the users see faster download times and improved application performance. It also means that low speed clients don’t destroy the performance of the WLAN for the rest of the users. This allows IT to implement a phased upgrade to 802.11n and immediately start reaping the benefits of the new 802.11n infrastructure even if it takes years to upgrade all of the clients. And, because a user connecting at the fringe of the WLAN can no longer consume all of the airtime, the network impact of a bad client or a weak coverage area is diminished –allowing IT to reduce infrastructure investment, save IT time and increase user satisfaction. Dynamic Airtime Scheduling, coupled with user and application based policy enforcement, allows IT to manage wireless network resources to transform a shared WLAN into a true multi-service network infrastructure that makes it possible to reliably move users and applications to the air.
Mixed Data Rates in Traditional Wireless LANs The 802.11 standards allow for all wireless devices within range and on the same channel to compete equally for the wireless medium, allowing only one AP or client to communicate at a time. Once an AP or a client starts to transmit a wireless frame, all other wireless devices on the same channel must wait until the transmission is finished before they can transmit. After a wireless frame has been successfully transmitted and the receiving device sends the wireless ACK, all devices, including the one involved in the previous transmission, have equal opportunity to gain access to the channel and use it for transmission. If a device is transmitting, the period of time that another device needs to wait before trying to transmit is determined by the size of the frame being transmitted and the transmit and receive data rates between the client and its AP. For example, a wireless frame transmitted to or from a client connected at a low data rate may utilize 10 milliseconds of airtime, whereas it may take only 100 microseconds for a client connected at a high data rate. Even though the high speed client could have sent 100 frames in the time the slow client takes to send one frame, the fast client still has to compete fairly for the airtime on a frame by frame basis, so it spends most of its time sitting idly waiting for the slow client to finish so it can have another chance to transmit. Unfortunately this means that a single low speed client can slow down all of the other clients on the WLAN. The following diagram demonstrates this point. It displays the elapsed time required to transmit eight frames to a high speed client, and at the same time transmit eight equal size frames to a lower speed client. Though the time required to transmit eight frames at a higher data rate is much shorter, the high speed client’s frames cannot be transmitted while the lower speed client’s frames are on the air.
Aerohive – New generation WLAN architecture
25
Copyright © 2009, Aerohive Networks, Inc.
Figure 21: Frames over time based on standard Wi-Fi behavior The frames transmitted at the lower data rate take more time, but in the end, both clients receive the same number of frames, finish at approximately the same time and achieve the same throughput. This is, by no means, an equal use of airtime. The traffic to the lower speed client consumes much more airtime than the faster client and prevents the fast client from benefiting from its higher data rate. If instead of giving an equal chance of transmitting a frame, you give equal airtime to clients, regardless of their data rate, the outcome can be improved for the higher speed client, with little to no impact on the lower speed client. The following diagram shows that by giving equal time slices to each client there can be many more frames transmitted to the higher speed client in the time it takes to transmit a single lower speed frame. In this example the higher speed client receives 4 frames for every frame sent to the lower speed client.
Figure 22: Frames over time based on equal airtime Over time, if both clients are downloading the same file, which in this example takes 8 frames to download, the higher speed client will finish much more quickly, leaving the rest of the airtime for the lower speed client. The low speed client takes approximately the same amount of time as it did in the previous example. If you factor in the added advantage of reduced contention, then the low speed client is also likely to finish more quickly. (Note: If you have more contention, the probability of collisions, random backoff times, and retransmissions increases thus lowering the performance for all clients that contend with each other. Therefore, getting the fast client off the air minimizes contention and helps to increase wireless LAN performance.) This is demonstrated by the following tests conducted using a VeriwaveTM WLAN test tool running a WiMix test. In the first test, the Veriwave connects a single wireless client and simulates a TCP-based HTTP file transfer from an Ethernet connected server by downloading 10,000 frames at 1500 bytes each. In the first test, the 802.11a wireless client is connected at 54Mbps, and in the second, 6Mbps. The results are shown in the following graphs.
Aerohive – New generation WLAN architecture
26
Copyright © 2009, Aerohive Networks, Inc.
Figure 23: Two simulated file transfers, one from a client connected at 54Mbps, and the other from a client connected at 6Mbps The 10,000 HTTP frames transmitted to the 54Mbps client takes approximately 12 seconds, while the transmission to the 6Mbps client with the same test takes approximately 50 seconds. The next test shows what happens when the clients share the air while 10,000 frames are being transmitted to each client. The WiMix is setup so that the clients share the wireless airtime but there is no wireless contention.
Figure 24: Comparison of simultaneous transmissions of 10,000 1,500 byte HTTP frames to simulate a file downloaded by a low speed client and a high speed client As you would expect, the total time to complete the two downloads is approximately 62 seconds, the sum of the 12 and 50 second download times for the two individual transmissions. You can also see that the two clients had almost identical performance, both showing 4000Kbps (4Mbps) of goodput with each client taking approximately 62 seconds to complete the task. The lower speed client consumed the airtime and slowed the faster client down to its speed, leading to very disappointing performance for the higher speed client. This problem can be dramatically improved by granting each client an equal amount of airtime rather than an equal chance of transmitting a packet. This minimizes the ability for low speed clients to reduce the performance of higher speed clients, while still giving low speed clients an equal share of airtime. Aerohive’s patent-pending Dynamic Airtime Scheduling accomplishes this goal by scheduling airtime based on IT-specified policies and improves client and network performance. The following chart shows the same two-client test case, but now with Dynamic Airtime Scheduling enabled.
Aerohive – New generation WLAN architecture
27
Copyright © 2009, Aerohive Networks, Inc.
Figure 25: Comparison of simultaneous transmissions of 10,000 1,500 byte HTTP frames to simulate a file downloaded by a low speed client and a high speed client with Aerohive’s Dynamic Airtime Scheduling The test shows that by scheduling airtime, the higher speed client finishes 4 times faster – a 300% performance increase, while the lower speed client finishes at approximately the same time. Fast client performance is dramatically improved and overall network capacity is increased without penalizing low speed clients.
Aerohive QoS Aerohive’s Dynamic Airtime Scheduling is built upon an existing capable and flexible QoS engine. The Aerohive Quality of Service (QoS) engines within HiveAPs provide highly granular prioritization and deterministic transmission of packets onto the wireless and wired networks. With Dynamic Airtime Scheduling, QoS is used to improve performance, but it also serves the other purpose of ensuring critical applications, such as voice, are handled with expediency. The Aerohive QoS capability consists of five main components: 1. Classifier and Marker – categorizes traffic into eight queues per user based on QoS classification policies. These policies can be configured to map traffic to queues based on network service, MAC OUI (Organization Unique Identifier), SSID and interface, or priority markings on incoming packets using IEEE 802.1p, 802.11e or DiffServ. The classifier is also responsible for marking traffic with IEEE 802.11e or DiffServ so it can be prioritized through the wireless LAN. Traffic going out an Ethernet interface can be marked with IEEE 802.1p or DiffServ. 2. Policer – rate limits traffic on a per-user, per user queue or per group basis to prevent a user, or an entire class of users (e.g., guests) from consuming excess network resources. 3. User Queues – 8 queues per user to allow for granular prioritization of traffic, and weighted access among clients. 4. Scheduler – uses strict priority and weighted round robin techniques to granularly schedule traffic from each of the eight queues into the Wireless Multi-Media (WMM) hardware queues. It does this by taking into account the configured weight of the user profile that is assigned to the user, and the configured weight of each of the user’s eight queues. Because the QoS packet scheduling engine runs on the HiveAP (rather than on a remote WLAN controller), it has the ability to closely monitor the availability of the WMM queues and instantly react to changing network conditions. The QoS packet scheduling engine only transmits to WMM queues when they are available, queuing packets in eight queues per user in the meantime. This prevents dropped packets and jitter, which adversely affect time-sensitive applications such as voice, and prevents TCP flow performance degradation caused by contention window back-off algorithms, which is when TCP packets are dropped.
Aerohive – New generation WLAN architecture
28
Copyright © 2009, Aerohive Networks, Inc.
5. Wireless Multi-Media Queues (WMM) –a standard mechanism for transmitting packets from hardware queues prioritized by four access categories: Voice (highest priority), Video, Best Effort, and Back Ground (lowest priority), to the wireless medium. Packets from higher priority access categories are transmitted with a smaller inter-frame space and a random back-off window to allow transmission to the wireless medium with less delay. These QoS engines are designed to add intelligence and control to a shared wireless network so that it can become a true multi-service network infrastructure capable of supporting a diverse range of users and applications. They allow bandwidth to be allocated to different users and groups – for example ensuring guests get 1/10 of the bandwidth that employees get during times of congestion but providing more bandwidth during quiescent times. And they ensure that time and latency sensitive traffic, such as voice and video, has priority over other types of traffic –e.g. file transfers and email— that are not as sensitive. These mechanisms can be implemented in a wireless LAN to help to assure that the voice quality for their VoWLAN phones or the quality of their video over the wireless LAN will not be impaired by large data transfers. These bandwidth based QoS mechanisms are very effective when clients are running at similar Wi-Fi data rates, or when airtime is not the bottleneck. However, clients at different data rates that consume different amounts of airtime, and slow clients consuming all the airtime and impairing network performance means that these bandwidth based QoS mechanisms are not sufficient to transform a shared WLAN into a true multi-service network infrastructure. Airtime needs to be managed and scheduled to truly enable a reliable, high performance, multi-service WLAN. Aerohive has made this a reality by delivering Dynamic Airtime Scheduling, a major enhancement to the QoS scheduling engine that allows the QoS scheduling engine to react based upon airtime consumption rather than bandwidth consumption. The QoS engines allow airtime scheduling to be used in conjunction with the rest of the HiveAP’s QoS capabilities, so that for example, critical voice traffic can still be treated with strict priority and forwarded ahead of other traffic, even if that voice client is using more airtime than it should. Combined with a flexible policy engine, IT has tremendous ability to implement user, group, device and application-based network bandwidth and airtime management policies.
Dynamic Airtime Scheduling Concepts and Examples Using bandwidth-based QoS scheduling mechanisms, or with no QoS at all, if traffic is being transmitted to or from clients connected at differing data rates, the faster clients throughput will slow down to the rate of the lowest speed client. This happens whether all clients are of the same type or if there is a mix of 802.11a/b/g/n clients. To demonstrate this, we used Veriwave WiMix to conduct tests to show the results of situations with and without Dynamic Airtime Scheduling enabled. Single Protocol (802.11a) with Different Data Rate Clients In the first test, we connect 3 clients that are all running the same 802.11a Wi-Fi protocol, but at three different data rates - 54Mbps, 12Mbps and 6Mbps. This simulates clients connected to the same AP but at varying distances or interference levels which cause the data rate to change. These tests simulate transferring 10,000 good 1500 byte HTTP packets for each client, showing the TCP goodput (traffic throughput that reaches its destination intact). The graph on the left shows that even though two of the clients are transmitting at a higher data rate, without airtime scheduling, they end up with throughput equal to the low data rate client. It takes all three clients 88 seconds to finish transferring 10,000 HTTP. Note: This test is conducted in a closed environment, and the clients wait their turn without contention. In a real life open air environment, the client contention would cause longer transfer times, though the behavior remains the same.
Aerohive – New generation WLAN architecture
29
Copyright © 2009, Aerohive Networks, Inc.
Figure 26: Three simultaneous file transfers, one test without and one test with Dynamic Airtime Scheduling The graph on the right shows the same test with Aerohive’s Dynamic Airtime Scheduling enabled. You can see that the transfer time for the 54Mbps data rate client is 4 times faster dropping from 88 seconds to 22 seconds. It finishes its transfer and frees up additional airtime for the remaining two clients to use. The 12Mbps client can now transmit more frequently, allowing it to finish in 2/3s the time at 59 seconds. Then the 6Mbps client can finish its transfer without contending for airtime, so it can transmit more quickly and it finishes at exactly the same time as in the first test. 802.11n Environments The next test adds 802.11n clients to the equation to simulate a typical WLAN’s transition to 802.11n – where 802.11n APs are servicing a mixture of 802.11n clients and legacy (a/b/g) clients. These tests show how Dynamic Airtime Scheduling enables a high performance 802.11n wireless LAN to not be hampered by clients connected at lower data rates – even if some of those slow clients are slow 802.11n clients. Depending on distance to the AP, position of the antenna or interference, the data rate of a connected .11n client can range from 13.5 to 270Mbps, so some 802.11n clients will be slower than other 802.11n client, and it is even possible that some 802.11n clients could actually be slower than fast a or g clients. To simulate this mixed n/a environment, we connect three 802.11n clients at 3 different rates on the 5GHz radio band of an AP. The rates used are 270Mbps, 108Mbps and 54Mbps (with frame aggregation enabled). Simultaneously we connect three 802.11a clients at 54Mbps, 12Mbps and 6Mbps. This simulates six mixed clients connected to the same AP but at varying distances or interference levels which cause the data rate to change. These tests transfer 10,000 good 1500 byte HTTP packets for each client. The graph to the left shows the results without airtime scheduling. As we saw in the previous 802.11a tests, each of the clients, though connected at different data rates, drops down to the throughput of the client at the lowest rate, which in this case is 6Mbps. The time it takes all 6 clients to finish transferring 10,000 HTTP packets is between 90 and 110 seconds.
Figure 27: Dynamic Airtime Scheduling in 802.11 environments
Aerohive – New generation WLAN architecture
30
Copyright © 2009, Aerohive Networks, Inc.
The graph to the right shows the same test with a HiveAP using Aerohive’s Dynamic Airtime Scheduling. The transfer time at the 270Mbps data rate is approximately 10 seconds – about 10 times faster than the 110 seconds seen in the previous test. Likewise, the rest of the transfer times improved significantly. The .11n(108Mbps) transfer was over 6 times faster, the .11n at(54Mbps) transfer was over 3x faster, the .11a(54Mbps) transfer was 2.5 times faster, the .11a(12Mbps) transfer was 30% faster, and the .11a(6Mbps) transfer decreased slightly (10%). As with the first test, with Dynamic Airtime Scheduling network performance is dramatically improved. All of the higher data rate clients saw substantial improvements in performance, while the low speed client saw almost no negative impact. In an open air network, the effects of the performance gain will even be higher, because once the higher speed clients finish, fewer clients are on the air, contention and retries decrease leading to performance increases.
Dynamic Airtime Scheduling in a Nutshell Now that you have seen what Dynamic Airtime Scheduling can do, let’s run through the main concepts of how it works. With bandwidth-based scheduling, the AP calculates the bandwidth used by clients based on the size and number of frames transmitted to or from a client. Bandwidth-based scheduling does not take into account the time it takes for a frame to be transmitted over the air. As discussed in previous sections, clients connected at different data rates take different amounts of airtime to transmit the same amount of data. By enabling Dynamic Airtime Scheduling, the scheduler allocates airtime instead of bandwidth to each type of user, user, and user queue, which can be given weighted preferences based on QoS policy settings. When traffic is transmitted to or from a client, the HiveAP calculates the airtime utilization based on intricate knowledge of the clients, user queues, per packet client data rates, and frame transmission times, and ensures that the appropriate amount of airtime is provided to clients based on their QoS policy settings. Dynamic Airtime Scheduling is made possible because it is performed directly on the HiveAPs responsible for processing the wireless frames. This gives the scheduling engine access to all the information needed in real time (at the microsecond level)), allowing the HiveAP to react to instantaneous changes in client airtime utilization, that occur when the client is moving or even stationary. Upstream Traffic and Dynamic Airtime Scheduling While the Wi-Fi standard does not currently allow an access point to force a client to not transmit, Dynamic Airtime Scheduling is still able to schedule and control upstream traffic. It measures the total airtime of the client including upstream traffic, and by aggregating both the sent and received traffic Dynamic Airtime Scheduling can ensure that client airtime consumption for both send and receive does not exceed its allotment. If a client is uploading a large file and attempting to consume more than its allotted airtime, the scheduling engine will queue that client’s downstream traffic, which will delay the transmission of protocol ACKs and slow the client’s transmission. The precision of scheduling is less than on the directly controlled downstream traffic, but the end result is that upstream airtime can be scheduled and controlled without having to resort to non-standard Wi-Fi approaches which can create client interoperability problems and interfere with neighboring networks. Voice over WLAN with Dynamic Airtime Scheduling When voice over WLAN services are used, Dynamic Airtime Scheduling is a complimentary technology that reduces contention in a mixed data rate environment, but it is not directly utilized for voice traffic. HiveAPs classify voice traffic into queues that use strict priority instead of scheduling with weighted round robin. The airtime for strict priority traffic is measured by the scheduling engine so that it can appropriately deduct the airtime used by voice in its scheduling decisions, but it does not schedule the transmissions of voice packets, instead it sends them directly to the WMM voice queue for immediate transmission. Because voice traffic uses small packets and is low bandwidth it does not consume much airtime and should only be transmitted with strict priority.
Aerohive – New generation WLAN architecture
31
Copyright © 2009, Aerohive Networks, Inc.
To demonstrate how voice calls are handled mixed in with clients using dynamic airtime scheduling, Veriwave WiMix is used to simulate 20 bidirectional VoIP calls using SIP (Session Initiation Protocol), while six clients connected at mixed 802.11n data rates are simultaneously downloading files using HTTP. The following graph shows six clients downloading 20,000 HTTP packets with two clients connected at 270Mbps, two clients connected at 108Mbps, and two clients connected at 54Mbps. Dynamic airtime scheduling ensures that the higher speed transfers finish quickly, freeing up the air for transfers at lower speeds.
Figure 28: Eight clients downloading files connected at different data rates (shown) while twenty other clients are simultaneously on voice over WLAN calls with toll quality (not shown) Simultaneously, the test tool simulates 20 wireless voice clients connected at a 54Mbps data rate, with bidirectional SIP voice calls. The following graph of the test output shows that each client maintains a consistent 88Kbps rate required for exceptional voice quality.
Figure 29: Example of twenty simulated SIP voice calls getting toll quality running concurrently with the eight simulated file transfers shown previously The test output from WiMix also shows that the Voice quality is exceptional with MOS scores for each call at 4.2 and R-Values at 85.5.
Aerohive – New generation WLAN architecture
32
Copyright © 2009, Aerohive Networks, Inc.
Giving Preference with Dynamic Airtime Scheduling The use of dynamic airtime scheduling is not just reserved for ensuring clients have equal airtime, it can also be used to give preference to users, types of users, SSIDs, client devices and network services. This can be used to give employees more airtime than guests if there is contention between them. For an example, let’s say you have two SSIDs, one for employees and one for guests. You can set the weight of the employee SSID higher than that of the guest SSID. If there is no wireless contention, both employees and guests get full use of the airtime. If employees and guests are using the wireless at the same time, the employees will get more airtime. The following picture shows the results of a Veriwave WiMix test that simulates simultaneous file downloads of 9 employees and 9 guests. To simplify the output of the test, employees and guests have 3 clients each connected at 270, 108, and 54Mbps data rates all downloading the same file.
Figure 30: Airtime preference given to employees vs. guests; Both the above graphs are from a single test run, it is shown as two separate graphs for simplicity given the number clients involved By giving the employee SSID more weight, you can see from the output that the employees get more airtime than guests, but within each group airtime scheduling still optimizes throughput of the clients running at mixed data rates. The weight preferences can be fine tuned to provide as much preference as desired. True Per-Packet Airtime Calculations vs. Protocol Based Scheduling Using Ratios With Dynamic Airtime Scheduling, the actual airtime in microseconds that is consumed by every frame is measured so that the scheduling engine makes its decisions based on true airtime consumption. Regardless of what wireless protocol is used, IEEE 802.11a/b/g/n, or what data rate clients are running at, each client is given its appropriate share of airtime based on actual airtime usage. This is significantly more accurate than Protocol Based Scheduling approaches that assume all clients running a given Wi-Fi protocol are running at the same data rate, and schedule traffic based on a fixed ratio between each Wi-Fi protocol. If a QoS system uses this kind of simplistic Protocol Based Scheduling that blindly assumes that .11g traffic is faster than.11b traffic, or simply prioritizes .11n traffic over .11g traffic, and does not take into account the actual data rate for the connected clients, the performance of the network can be adversely affected. In a worst case scenario, Protocol-based Scheduling can actually make a network perform slower than with no QoS at all! In addition, Protocol-based scheduling does nothing to address the issue of slow 802.11n clients impacting faster 802.11n clients. The following picture shows that Protocol-based Scheduling does nothing to address fast and slow clients running the same Wi-Fi protocol (e.g. 802.11n). The graph shows file downloads from two clients - a slower 802.11n client connected at a 54Mbps data rate, and a fast 802.11n client connected at a 270Mbps data rate. Here the lower rate .11n client is able to slow the faster client, just as discussed earlier in the paper when no airtime scheduling was enabled. This issue becomes particularly important with the transition to .11n where more and more clients deployed in the network
Aerohive – New generation WLAN architecture
33
Copyright © 2009, Aerohive Networks, Inc.
will be .11n and where the data between a fast and slow client can vary so substantially (e.g. from 270Mbps to 13.5Mbps).
Figure 31: Protocol-based scheduling with different speed clients of the same protocol True per-packet airtime scheduling will always optimize airtime utilization no matter the environment, while simplistic protocol-based scheduling systems must make coarse assumptions which limit the applicability, and performance benefit of the feature.
Conclusion Aerohive’s Dynamic Airtime Scheduling is an exciting and innovative new technology that provides QoS based on airtime instead of just bandwidth. Managing airtime is critical because airtime consumption affects all of the clients on the network. It needs to be dynamically managed because it varies widely across all of the clients on the network – not just because clients are running different Wi-Fi protocols, but also because of instantaneous changes in relative closeness to the AP, signal strength, interference and error rates. With Dynamic Airtime Scheduling, airtime can be dynamically scheduled to increase network and client performance and to allocate network capacity based on ITspecified policies. Dynamic Airtime Scheduling increases the performance of wireless networks and transforms a wireless LAN into a true multiservice network infrastructure.
Aerohive – New generation WLAN architecture
34
Copyright © 2009, Aerohive Networks, Inc.
SLA COMPLIANCE: WIRELESS FIDELITY ACHIEVED The problem Networks are living creatures, ever-growing, ever-changing, and Wi-Fi networks change even more quickly and in more ways than wired networks. New APs are deployed, neighboring networks pop up, clients roam, data rates change, flash crowds converge on one part of the network. Users love the freedom and mobility, but they also are demanding that IT consistently deliver them predictable performance in spite of the dynamic nature of the network. Wi-Fi networks are getting faster and smarter and that helps. But Wi-Fi administrators are still hampered by having minimal visibility into how well they are actually delivering what their users expect. They don't have visibility into the actual performance level being provided to the Wi-Fi clients by the infrastructure and their infrastructure only has limited ability to dynamically adjust to deliver the experience their users are demanding. Today's Wi-Fi administrators can only hope their clients are getting the planned level of performance - and that isn't good enough. Before Wi-Fi protocol analyzers, administrators and consultants alike were only able to troubleshoot by continually reviewing the network design of and device operation within the network infrastructure. Gathering meaningful performance statistics and performing trouble analysis and repair was difficult, if not impossible. With the introduction of Wi-Fi protocol analyzers, these professionals had the equivalent of RF goggles. They could now see what was happening and could reactively troubleshoot problems. The problem with this approach is a lack of ability to properly diagnose and repair performance problems in near real-time. With this in mind, Aerohive has introduced the next level in network visibility and reactive response. Aerohive's new infrastructure-side performance monitoring and response system, dubbed SLA Compliance, increases the troubleshooting granularity and active response speed far beyond what any IT professional could accomplish manually and paves the way for IT to move towards actual performance guarantees.
Wi-Fi That Works Some call it Wi-Fi Utility. Others call it network determinism. We call it Wi-Fi that works. The IEEE’s plan for the 802.11 standard has always been to implement inter-AP protocols to do the work of client handoffs, spectrum management, and much more. Aerohive aligned its thinking and methodology with that of the IEEE, building its own high-performance Cooperative Control protocols between its HiveAPs. Then the Wi-Fi Alliance began with an advertising slogan of, “The Standard for Wireless Fidelity.” Again Aerohive has answered that call, implementing real Wireless Fidelity, when defined means: adherence, reliability, integrity, precision, and surety. We believe that there should be some baseline of performance that you can count on – or even better – guarantee. Every network technology has to start somewhere and then progress forward. First, Ethernet was established in data centers, and then in distribution and access layers. Next a variety of Internet access technologies such as dial-up and ADSL were introduced. Now it’s Wi-Fi’s turn. We take most of these connectivity technologies for granted, and Wi-Fi should be no different. There are several parameters that factor into utilitarian networking. Let’s take a look at some of those factors. A Simple Machine Does it work every time you need it? If you haven’t tinkered with it in a while, will it still give you unwavering dependability? Unfortunately, the answer is often no. So, the challenge is to build the equivalent of a networking simple machine. We know that a lever, a pulley, or an inclined plane is going to function every time. It’s in their nature. That’s what we need here as well, only we’re dealing with over 2,600 pages of the IEEE 802.11 standard (with amendments), so that’s no simple undertaking. The concepts we’re talking about are reliability, availability, and predictability. The first rule of building a reliable system is to remove all unnecessary parts, and that is where simple machines get their names. One relevant example of minimization: replacing a Wi-Fi controller with inter-AP protocols. Protocols are either on or off. They don’t experience wear and tear, they don’t use
Aerohive – New generation WLAN architecture
35
Copyright © 2009, Aerohive Networks, Inc.
any power, they don’t require licensing or warranties, and they don’t take up space in a landfill when they die. And make no mistake, controllers die. When your network is mission critical, nothing less than just works will do. Words like partially, mostly, and sort of just won’t cut it. Industry Response To-Date Vanilla 802.11 is a distributed free-for-all, devoid of certainty, and where Wi-Fi is used only as a network of convenience, performance is often near the bottom of the priority list. Due to Wi-Fi’s transition to mission-critical status in the enterprise, vendors have been incrementally delivering features that offer measures of improved performance. These features generally fall into two categories: prioritization and optimization. You may have heard of some of them: WMM QoS, Bandwidth Management, and Airtime Fairness. Some of these features are better than others, and all of them are a step in the right direction, but they are simply pieces of a larger puzzle. Today’s leading enterprise-class Wi-Fi solutions attempt to optimize client performance and deliver predictable behavior. However, they are unable to effectively report on whether they were successful in delivering this performance and have no automated response mechanism for when they are unsuccessful. This is where Aerohive has innovated. Aerohive’s new Performance Sentinel and Airtime Boost features provide network administrators with unprecedented levels of Wi-Fi visibility and determinism by monitoring every client’s throughput performance against its predefined service level agreement (SLA). Additional airtime is automatically allocated to those clients that are not meeting their SLA so that they can be moved into compliance. These two features are each a first in the Wi-Fi industry.
The Big Picture Real wireless fidelity requires a holistic approach to SLAs. Figure 2 illustrates the industry’s step-bystep progression toward SLA monitoring and actions. A holistic approach must include the ability to ensure a throughput requirement is achieved through: -
SLA definition & monitoring: enables the administrator to specify a minimum throughput threshold.
-
Problem analysis: isolates problems down to client or AP when there is a violation.
-
SLA actions: dynamic resource allocation to recover from violations SLA visibility, faultrecovery actions, and in-depth analysis will allow the network administrator to see the big picture while the Wi-Fi platform does all of the work.
Figure 32: The Progression from Convenience to Fidelity
Aerohive – New generation WLAN architecture
36
Copyright © 2009, Aerohive Networks, Inc.
What does Ms. Smith, the payroll clerk, care about WMM traffic prioritization or airtime scheduling? She doesn’t. She, like all other Wi-Fi users, wants to know that her network connection will give her what she’s supposed to have wherever and whenever she goes. She wants a guarantee. It’s just that simple. Ms. Jones, the network administrator, wants something too, but her perspective is different. Ms. Jones wants Ms. Smith to get the expected network behavior, and if that doesn’t happen, she wants to know when, why, what action was taken, and whether or not the action repaired the problem. Before this can happen, SLAs must be defined, monitored, and enforced.
SLA Compliance – How It Works Aerohive now delivers two industry firsts, introducing a new realm of determinism and network visibility. These two features enable IT, for the first time, to establish, monitor, and deliver throughput guarantees for Wi-Fi clients. Performance Sentinel In order to monitor the network, Aerohive has introduced Performance Sentinel – a client throughput service level monitoring engine. Performance Sentinel characterizes wholenetwork performance, from a throughput perspective, and reports on achievement from a single dashboard (e.g. 98% of our clients achieved 3 Mbps throughput or greater for the last 3 months). In Figure 3, HiveManager’s SLA reporting shows that 3 clients on a single AP were in violation of the SLA (Red). When Airtime Boost (discussed in the next section) is enabled, reporting shows all clients and APs are SLA-compliant, 3 clients being compliant as a result of the Airtime Boost action (Yellow).
Figure 33: Network Visibility (APs & Clients) – The Dashboard Performance Sentinel compares client throughput and demand with a predefined throughput SLA level by: - Using client data statistics to determine client throughput. - Using buffer statistics in the QoS engine to determine if a client is actually trying to download more data. In addition to client-side visibility, APs can also be monitored to pinpoint which had clients with SLA violations, which could be the result of interference or capacity problems.
Aerohive – New generation WLAN architecture
37
Copyright © 2009, Aerohive Networks, Inc.
Airtime Boost In order to provide automatic recovery action for stations not meeting their SLA, Aerohive has introduced Airtime Boost – a feature built on Aerohive’s innovative Dynamic Airtime Scheduling engine that automatically allocates additional airtime to lagging stations. Airtime Boost is the first available among multiple actions that may be taken in an Aerohive system to assist a struggling client in meeting its SLA.
Figure 34: Airtime Boost Functionality Aerohive’s Dynamic Airtime Scheduling feature allows fast clients to achieve high throughput and slow clients to achieve their normal level of throughput without unfairly penalizing either client type. Applying Airtime Boost technology to user profiles allows IT to pre-configure the system to assist particular stations in achieving their SLA when a problem is noted by Performance Sentinel. Now IT can create different classes of clients (user profiles), give them different SLA levels, and have the system automatically respond if they are not being met. Some examples: - Medical imaging clients need 6 Mbps throughput to work properly - Administration clients work fine with 3 Mbps throughput - Guest clients could be set at 1 Mbps and only logging non-compliance
Figure 35: Airtime Boost: Building on Dynamic Airtime Scheduling IT administrators now have a dramatically-simplified client performance analysis engine that: - Easily isolates problems to client or AP when there is an SLA violation, before the user has had time to complain. - Provides simple drill-down to a rich set of statistical information on the client or AP, including: identity, data sent/received, data rates, RSSI values, performance, errors, interference, load, and airtime usage Top offender lists are provided along with compliance history.
Aerohive – New generation WLAN architecture
38
Copyright © 2009, Aerohive Networks, Inc.
Figure 36: Drilling Down Into Client Sessions
SLA Compliance – Making It Happen Let’s look at an example of the power and usefulness of SLA compliance features. In the figure hereafter, Group-1 has a client SLA of 6 Mbps, and Group-2 has a client SLA of 2 Mbps, but neither group has any SLA actions set. For that reason, all 6 client devices have similar throughput, although Group-1 clients are in violation of their SLA.
Figure 37: Example 1 In the next figure, Airtime Boost is enabled. Group-1 clients are automatically given more airtime, which decreases the throughput for the clients in Group-2 but still keeps them performing above their SLA. In this scenario, the actions taken by Airtime Boost allow clients in Group-1 and Group-2 to achieve their SLA throughput levels.
Figure 38: Figure 2
Aerohive – New generation WLAN architecture
39
Copyright © 2009, Aerohive Networks, Inc.
It really is as simple as that. Sure, there’s some rocket science behind it, but the administrator will never have to see all of those details. Making the magic happen is our job. Configuration In HiveManager’s User Profile configuration section, it’s only a matter of enabling the SLA feature with a click, choosing a bandwidth value, and then choosing your action from the list in the drop-down.
Figure 39: SLA Configuration in HiveManager’s User Profile Again, this is a simple machine. We believe that when it comes to user interfaces, it’s a matter of simplify or die.
Conclusion Aerohive has again innovated to bring its customers market leadership in wireless determinism through performance guarantees, architecture simplification, highperformance, and low cost. The ability to set SLA parameters per user group, to monitor SLA statistics in real-time, and to take significant corrective action when and where needed is an industry first and is included in Aerohive systems at no additional cost. The goal of delivering a level of wireless fidelity that allows applications to be moved from the wire to the air has been achieved. Now wireless can truly become the primary access layer.
Aerohive – New generation WLAN architecture
40
Copyright © 2009, Aerohive Networks, Inc.
PRIVATE PRESHARED KEY The problem Wireless networking has gone through several evolutionary steps to equal – and in some cases, exceed – the security found in wired networks. The first step in this evolution was the development of preshared keys, or PSK. Each device in a network uses a preshared key to encrypt traffic, thus providing additional security. The disadvantages of classic PSK include the fact that it is impossible revoke the network-wide key should an individual leave the organization, as well as the fact that it is relatively easy to crack. Today, the clear choice in authentication for enterprises that are deploying or upgrading wireless networks is 802.1X. However, moving from PSK to 802.1X can prove to be challenging, as some devices do not support 802.1X or are cumbersome to set up. This can lead to the choice between the purchase of new equipment or a compromise in security. 802.1X also faces challenges when used to secure devices not owned by the enterprise, such as those of guests, students, subcontractors or the like. Because 802.1X requires the installation of a software client, it is difficult or impossible to use on such unmanaged devices. Aerohive’s patent-pending Private PSK provides the ease of PSK with many of the advantages of 802.1X solutions. The IT manager can provide unique passphrases to each user on a single SSID, which creates a one-to-one relationship between the key and user instead of the one-to-many paradigm of classic PSK, thus providing the ability to truly authenticate each individual. This enables 802.1X-like capabilities even though it appears like only a PSK is required on the laptop or Wi-Fi device. While classic PSK does not allow the revocation of a single user’s credentials since all users share the same passphrase, Private PSK offers a unique PSK per individual and therefore enables the administrator to revoke a single set of credentials. Furthermore, since Private PSK, like 802.1X, allows a means to identify individual, users on a single SSID, each can be granted different user profiles. This allows all users to connect to the same network, but get unique levels of service based on their roles. Benefits -
Simple key creation, distribution and revocation saves administrator time and reduces the cost and complexity of using a single PSK or trying to get hard-toconfigure devices online using 802.1X.
-
Guests can be given unique keys, thereby eliminating the risk of one guest eavesdropping on another. In addition, entering a PSK is often simpler than loading up a captive web-portal and entering a username and password.
-
If a person leaves the company, classic PSK requires that the key be reset for all users, which can be an IT support burden. With Private PSK, just that one user’s key can be revoked.
-
Many clients do not support 802.1X or the latest WPA2 standard with opportunistic key caching required for fast roaming between APs. With Private PSK, those clients can see significant performance increases with roaming
-
Many legacy clients don’t support 802.1X but most will support WPA-PSK. Those clients can be made secure without a costly client and application upgrade.
Overview of Common Methods for Wi-Fi Access When implementing a wireless LAN, organizations must chose a means by whichusers prove that they are who they say that they are. This choice often involves a compromise between complexity and security.
Aerohive – New generation WLAN architecture
41
Copyright © 2009, Aerohive Networks, Inc.
The three most common methods for new deployments are: -
Open Authentication – No Wi-Fi security: o All traffic is sent in the clear. o May use captive web portal for self registration or authenticated access. o May segment traffic to specific VLAN or network.
-
Preshared Key – IEEE 802.11i WPA or WPA2 Personal: o Uses a single secret key that is shared among all clients and APs for an SSID. o The shared key is used for encrypting traffic between the clients and APs with TKIP or AES-CCMP.
-
IEEE 802.1X (EAPOL) – IEEE 802.11i WPA or WPA2 Enterprise: o Authenticates users and, optionally, their client devices, based on user credentials and machine certificates. o The keys used by client and AP are securely and dynamically negotiated with the RADIUS server using 802.1X (EAPOL). o The APs and clients use the key to generate secure temporary keys for each session with RADIUS. o Traffic is encrypted with TKIP or AES-CCMP.
SSIDs with open authentication are the easiest to configure, and as a result, many enterprise guest networks are set up using this method. There are significant problems with this configuration, however, especially with security. All traffic to and from clients is sent in the clear, and there is no control as to who associates with the open SSID. Many Wi-Fi capable devices may even connect automatically, without a user even being aware of it. This leaves the wireless device open for attack, and can place an extra burden on the Wi-Fi infrastructure. SSIDs with preshared keys have several advantages over open authentication. In addition to being more secure, they are easy to set up, are widely supported by clients, and do not require authentication servers, certificates, or extra configurations on the clients. Despite these benefits, however, the fact that all users on the same SSID must use the same key creates a number of problems. If one user leaves the organization or loses their wireless client, the preshared keys on the access points and all clients must be changed to protect the wireless LAN from unauthorized access. Also, all users on the SSID must belong to the same user profile and, therefore, share the same QoS rate control and queuing policy, VLAN, tunnel policy, firewall policies, and schedules. It is not possible to provide different network policies to different users on the same SSID when applying PSK-based authentication. SSIDs that use IEEE 802.1X authentication solve the shortcomings of PSKs by providing a unique key to each individual user. After a user authenticates against a RADIUS server, the server sends the access point and client a unique PMK (pairwise master key) from which they generate PTKs (pairwise transient keys) to use during their session. The RADIUS server can also return attributes to identify different user profiles. With this approach, 802.1X authentication overcomes problems inherent in the classic PSK solution by allowing multiple user profiles per SSID based on individual authentication. This also provides the ability to invalidate users or machines when a user leaves or their machine has been lost, stolen, or compromised. However, 802.1X requires a more involved setup, including a RADIUS server, server certificates, and a user database stored either on the RADIUS server or on an Active Directory or LDAP server with which the RADIUS server communicates. In addition, the clients, or RADIUS supplicants, require additional configuration to support 802.1X.
Aerohive – New generation WLAN architecture
42
Copyright © 2009, Aerohive Networks, Inc.
Wi-Fi Access using Aerohive Private PSK Though using IEEE 802.1X is the most secure approach to Wi-Fi authentication, this method is typically only implemented for devices managed by IT staffs, where they have control over the domain infrastructure, user accounts, and wireless clients being used. For temporary users such as contractors, students, or guests, the IT staff may not have the access rights required, the knowledge to configure 802.1X clients for all the different wireless devices involved, or even the time to perform such tasks. Even more difficult is the fact that many legacy wireless devices do not support 802.1X or the latest WPA2 standard with opportunistic key caching required for fast roaming between APs. The next best option has traditionally been to use a preshared key for these devices. As we’ve discussed earlier, however, classic PSK trades off many of the advantages of 802.1X such as the ability to revoke keys for wireless devices if they are lost, stolen or compromised, and the extra security of having unique keys per user or client device. To draw on the strengths of both preshared key and IEEE 802.1X mechanisms without incurring the significant shortcomings of either, Aerohive has introduced a new approach to WLAN authentication: Private PSKs. Private PSKs are unique preshared keys created for individual users on the same SSID. They offer the key uniqueness and policy flexibility that 802.1X provides with the simplicity of preshared keys. The following diagram is a simple example showing a WLAN with traditional preshared keys versus that of a WLAN using Aerohive’s Private PSK functionality. With the traditional approach, all the client devices use the same preshared key, and all receive the same access rights because the clients cannot be distinguished from one another.
Figure 40: SSID with Preshared Key vs. SSID with Private PSK On the other hand, with private PSK, as shown on the right, every user is assigned their own unique or “private” PSK which can be manually created or automatically generated by HiveManager and then sent to the user via email, printout, or SMS. Every private PSK can also be used to identify the user’s access policy including their VLAN, firewall policy, QoS policy, tunnel policy, access schedule and key validity period. Because the keys are unique, no key from one user can be used to derive keys for other users. Furthermore, if a device is lost, stolen, or compromised, the individual user’s key can be revoked from the network, preventing unauthorized access from any wireless device using that key. As for the client users, the configuration is the same as using a standard preshared key.
Aerohive – New generation WLAN architecture
43
Copyright © 2009, Aerohive Networks, Inc.
Wireless LAN Requirements & Features No complex configuration required for clients Unique Keys Per User On Single SSID Can revoke an individual user’s key or credentials when they leave the company or their wireless device is compromised, lost or stolen Supports different VLAN, QoS, Firewall or Tunnel policy for different users on same SSID Does not require clients to support opportunistic key caching for fast roaming Does not require certificates to be installed on clients Uses 802.11i standard mechanisms for securing the SSID Keys are dynamically created for users upon login to the network and are rotated frequently Can be used to perform machine authentication If one user is compromised, no other users keys can be compromised
PSK WPA/WPA2 Personal
Private PSK WPA/WPA2 Personal
IEEE802.1X WPA/WPA2 Enterprise
Depends on client
Table 2: PSK versus PPSK versus 802.1X
Private PSK Deployments Using HiveManager Whether or not devices are managed by the corporate infrastructure, the configuration of Private PSK can be greatly simplified using HiveManager. HiveManager is used to configure the WLAN policy, which defines the configuration for HiveAPs including the SSIDs. Diagram 2 shows a WLAN policy that is used to establish a Private PSK - SSID on HiveAPs. In this case, HiveManager is then used to automatically generate a Private PSK user database for corporate devices that are unmanaged, such as smart phones, and a set of Private PSK users for guests. Each Private PSK user has its own preshared key and is assigned to a group from which its policy is inherited. In step 1, the administrator configures the Private PSK SSID and creates the user database which is pushed to the HiveAPs. These users can be manually configured, automatically generated or loaded into the HiveManager using a .csv file, such as an export file from Active Directory.
Figure 41: HiveManager Configuration and Private PSK Generation and Distribution
Aerohive – New generation WLAN architecture
44
Copyright © 2009, Aerohive Networks, Inc.
In step 2, the administrator can click a button in HiveManager to email the individual private PSKs to selected users. This is demonstrated in Figure 3. When the user receives the email, they can use their unique PSK to connect to the wireless network.
Figure 42: Emailing Private PSKs to Users In step 3 the clients, loaded with their unique keys can access the network and be assigned their unique policy.
Figure 43: Revoking Private PSKs If a person leaves the company or loses their key, the key can be revoked as is shown in the figure below. By simply selecting Private PSK users, clicking remove and updating the user database on HiveAPs, the keys can be removed from wireless LAN preventing access from any device using these keys.
Securing Guest Access with GuestManager and Private PSK Using GuestManager’s Private PSK implementation, a lobby administrator can use a simple webbased interface to allocate guests their own Private PSKs that can be time limited and revoked if necessary. Using GuestManager with Private PSK, you get the additional benefits of a: - Simplified web interface used to allocate Private PSKs to guests. - Customizable print templates that can be used by lobby administrators to print account keys and logon instructions for guests. - Guest revocation using RADIUS Dynamic Change of Authorization Messages (RFC 3576) that does not require updating the user database on HiveAPs. - RADIUS accounting. An example of how GuestManager operates with Private PSK is demonstrated in the steps displayed in the following figure.
Aerohive – New generation WLAN architecture
45
Copyright © 2009, Aerohive Networks, Inc.
Figure 44: GuestManager Operation with Private PSK The 6 steps are: 1. The administrator creates the necessary WLAN policy configuration which includes the SSID, user profile, and Private PSK configuration in HiveManager. The Private PSK configuration parameters include a key regeneration timeframe, secret key, location, and an option to validate keys with GuestManager. The administrator can create up to 1000 private PSKs for a location. Once HiveAPs are updated, based on the key regeneration time, the HiveAPs will generate keys for the Private PSKs. 2. To allow the delegation of control and distribution of Private PSKs, the administrator then configures the same Private PSK parameters into the GuestManager. This enables GuestManager to generate the exact same PSKs that are generated on HiveAPs, including the same key regeneration times. However, the control as to whom the Private PSKs are given, and when the PSKs are active can now be given to a delegated administrator such as a lobby administrator, without the need for them to touch the configuration of HiveAPs. 3. As guests arrive, the lobby administrator with limited web access can create a guest Private PSK user account (Figure 6). Once created, the lobby administrator clicks a button to print login credentials and instructions for the guest.
Figure 45: Lobby Administrator Creates Guest Account
Aerohive – New generation WLAN architecture
46
Copyright © 2009, Aerohive Networks, Inc.
4. Guest users authenticate their client devices to the guest SSID using their unique Private PSK. 5. HiveAPs validate the Private PSK with GuestManager using the Private PSK as a user account to ensure the account is still active. If permitted, GuestManager will send an access accept to the HiveAP to permit the user to login to the wireless LAN. GuestManager can also be configured to return RADIUS attributes to assign the user profile assigned to the user. By combining the steps of using the Private PSKs for encryption, and for validating the user with RADIUS, this method ensures that only valid guests will be able to securely access the network. If the lobby administrator revokes the guest user from GuestManager, GuestManager will send a RADIUS change of authorization message to the HiveAP which flushes the user’s authentication cache from all APs in the Hive, forcing the client to reauthenticate. However, if the user has been revoked, the RADIUS authentication will fail and the user will not be granted access to the wireless LAN.
Summary Today, 802.1X is regarded as the gold standard for Wi-Fi security and authentication by industry analysts, vendors, and enterprise IT managers. Unfortunately, the wholesale migration to 802.1X is inhibited by the cost of upgrading legacy clients, the deployment complexity of 802.1X, and the inability of guest networks to work with it. Aerohive’s Private PSK addresses the security and management challenges of legacy clients, mobile devices, and guests that cannot be moved to 802.1X, allowing enterprises to use 802.1X where they can and Private PSK everywhere else. This dramatically improves Wi-Fi security and manageability while it reduces wireless LAN deployment and operating costs.
Aerohive – New generation WLAN architecture
47
Copyright © 2009, Aerohive Networks, Inc.
BEST PATH FORWARDING Utilizing Best Path Forwarding, a key technology in Aerohive Networks’ cooperative control architecture, HiveAPs cooperate with neighboring HiveAPs to support distributed data forwarding functions such as layer 2 routing, optimal path selection and high availability.
Scalable layer 2 routing and optimal path selection For best path routing capabilities, HiveAPs utilize the Aerohive Mobility Routing Protocol (AMRP). Using AMRP, HiveAPs cooperate with each other to determine the best path through a wireless network and have the ability to forward traffic locally using the best path. This is a significant improvement over centralized wireless LAN controller-based solutions, which perform control functions and forward data from a centralized location. In order to determine the best paths through a network, HiveAPs run AMRP over both wired and wireless LAN connections. This allows the routing algorithms to determine the best path, based on link costs and hops, whether it is over the wired LAN or wireless mesh uplinks. If a wired or wireless uplink fails, the new route information is propagated instantaneously through the wireless LAN. This allows HiveAPs to select a new best path for seamless rerouting and forwarding of traffic. Finally, to enable the ability to support large scale wireless LAN installations such as large corporate campuses, AMRP has been designed to limit the messages and routing information within selfcontained areas. This limits the number of route table entries that a single HiveAP needs to maintain. This also limits the amount of broadcast traffic within a wireless mesh. The diagram below depicts an example of the differences between centralized control and centralized data plane architecture found with most wireless LAN controller architectures as compared to Aerohive Networks’ distributed data plane and best path distributed forwarding.
Figure 46: Centralized vs. Distributed Data Forwarding With the centralized control and centralized data plane architecture, all wireless traffic is directed to a dedicated wireless LAN controller, which may be many hops away or even at a different location. Because of the indirect paths and round-trip times between the APs and the controllers, extra latency (the delay through a device) and jitter (the variable amount of delay through a device) are introduced, which has adverse affects on wireless LAN performance and voice quality. This is especially prevalent if the path to the controller or the controller itself is heavily utilized. In contrast, the Aerohive cooperative control architecture utilizing AMRP allows for best path forwarding between devices over the LAN and over wireless mesh, preventing extra latency and jitter as traffic passes between devices. This is essential for achieving high performance and exceptional voice quality.
Aerohive – New generation WLAN architecture
48
Copyright © 2009, Aerohive Networks, Inc.
Security with Best Path Forwarding Utilizing the cooperative control wireless LAN architecture with best path forwarding, authentication, encryption, DoS mitigation, and firewall access control, security is enforced at the HiveAP before traffic is forwarded onto the network. Once that traffic is on the campus network, the wireless LAN traffic can benefit from the existing security implementations such as firewalls, antivirus gateways, and intrusion detection and prevention systems that have been implemented to inspect and secure the rest of the enterprise traffic. This is in contrast with controller-based solutions that opaquely tunnel all of this traffic around the existing network security infrastructure and often require the purchase of additional security infrastructure, or the redirection of traffic exiting the controller back to these security devices for additional inspection.
Scalability with Best Path Forwarding Performance scales linearly as the number of HiveAPs increases. Each HiveAP makes its own forwarding decisions and uses best path forwarding to transmit data. With no central traffic forwarding device that can become a bottleneck, the HiveAPs can take full advantage of the performance and capacity of the wired network infrastructure, giving full non-blocking performance. This is important today and becomes essential when IEEE 802.11n is available which will increase the performance of wireless LANs up to 10 times.
Wireless Mesh Using cooperative control protocols that run over the air as well as over the wired LAN, HiveAPs can establish wireless mesh connections with neighboring HiveAPs that share the same hive credentials. HiveAPs have two radios, allowing one radio to be dedicated to wireless access and the other for wireless uplink connections. This prevents interference in wireless access by the communication from wireless uplinks, increasing the throughput for the wireless LAN. In addition, each HiveAP wired to the LAN infrastructure provides more wired uplink bandwidth for the wireless mesh. Wireless mesh can be used where wired connectivity is not feasible, for temporary networks that may be used for conferences or emergency situations that must be deployed rapidly, or for wireless mesh redundancy in the event that an Ethernet cable is accidentally disconnected or access switch fails. All you need is power. The HiveAPs can automatically build wireless mesh uplink connections with each other to provide wireless coverage that is not limited to Ethernet’s 100 meter maximum twisted pair length as defined in the 10/100/1000BASET standards for twisted pair.
Figure 47: HiveAPs Configured within a Wireless Mesh
Within the wireless mesh, cooperative control protocols are used to provide best path forwarding, seamless roaming, optimal radio channel selection for wireless access and uplink connections, and high availability with dynamic and stateful rerouting of traffic in the event of a failure.
Finally, because cooperative control protocols have been designed to scale to support very large wireless mesh networks, they prevent flooding by limiting the scope of broadcasts, the distribution of routes, and the distribution of roaming cache information. This, in combination with QoS, DoS prevention, and firewall policy enforcement at the HiveAP, keeps unnecessary traffic off of the mesh, ensuring optimized wireless LAN performance.
Copyright © 2009, Aerohive Networks, Inc.
HIGH AVAILABILITY Distributed architecture rchitecture for native high availability A distributed architecture approach is the only proven model when building uilding highly scalable and resilient architectures. The he Aerohive solution also provides many other unique features. Deploying today’s s applications such as RFID, Voice and clinical data and and showing how LAN failures do not affect them has been proven on the the Aerohive solution. We discuss the highlights of the features that can provide the Trust with a highly resilient network. -
Aerohive provides Application level stateful redundancy: if voice over Wireless LANs is to become the prime form of communication, itit is important that the solution can suffer failures while maintaining the call. A user must maintain connectivity throughout and not have to re-dial dial a number if parts or multiple parts of the network fail. o
Aerohive is unique in offering session level fail over for voice calls (and data) Aerohive can suffer a failure in both the control and data plane and still maintain call connectivity. This has been demonstrated in other trusts by showing how the failure of a single AP or multiple APs, and the failure failure of the Ethernet can occur concurrently and still maintain voice connectivity.
o
By contrast controller based solutions are not stateful. If a controller fails, the APs may reboot at worst, or at best, use a VRRP type of technology to failover. In all casess the voice call will be affected.
o
It is also worth noting that the design guides for controller based solutions suggest that APs in a common area, where users are roaming are connected to the same controller. So the impact of -the controller failing will affect every AP in that given area.
Figure 48:: Controller failing and affecting affec every access points -
Aerohive provides Dynamic Mesh M routing protocols: routing protocols for LANs were designed to build high levels of redundancy into wired networks and the benefits are well understood. Aerohive has built advanced routing protocols (Cooperative Control) into the wireless LAN which will dynamically route around around failures in the wired infrastructure. Cooperative Control routing protocol has the unique capability of a health checking service availability in the LAN network and will dynamically act upon LAN availability. For example, should an upstream server or gateway fail, it is possible to either route around the issue or actually turn off the advertisement of the wireless LAN until it is restored.
Figure 49: Self-Healing Healing Resilience with Dynamic Mesh Failover
Copyright © 2009, Aerohive Networks, Inc.
-
Aerohive provides non-impactful maintenance upgrades: with Aerohive’s fully distributed architecture it is possible to upgrade individual APs and schedule reboots individually and thereby maintain uptime in the WLAN. The net effect of this it is possible to upgrade the network with no scheduled downtime and no impact to application delivery. This is wholly different for controller based systems that require the controller to reboot, which in turn reboots all the APs connected and affects the WLAN uptime.
-
The Aerohive solution has NO single point of failure: a fully distributed architecture means that the Aerohive solution provides N x X redundancy. Controllers offer at best N x 1 redundancy, and the failure of a controller effects every AP connected to the controller.
-
User identity caching: part of the security feature set enables integration from an imbedded RADIUS server to cache user credentials so should a failure happen between the AP and the backend directory structure users can still access the network. Very useful in distributed environments like branch offices scenario where survivability of the branch is critical: user identity caching enables caching of user credentials to prevent downtime when there is a loss of connectivity with the central site by caching user credentials (hash) in volatile HiveAP memory such that if there is a WAN failure, authentication will continue to work.
-
Dual Homed Access Points: the HiveAP320 and HiveAP340 each have two Gigabit Ethernet interfaces allowing for the AP to be connected to 2 separate Ethernet switches which provides additional protection against failures in the LAN infrastructure.
The diagram hereafter summarizes the different high availability features implemented in Aerohive Cooperative Control architecture.
Figure 50: Reducing risk with wired-like resilience
Aerohive – New generation WLAN architecture
51
Copyright © 2009, Aerohive Networks, Inc.
Automatic re-routing upon network failure Using the cooperative control wireless LAN architecture, HiveAPs do not have a single or central point of failure. If a single HiveAP fails, stations automatically move to neighboring HiveAPs just as they would if they were roaming, without loss of authentication, security, QoS parameters or session state, and without interruption of data or voice connections. In addition, with cooperative control routing protocols and a distributed data plane, if HiveAPs within the mesh fail, Ethernet uplinks are disconnected, or Ethernet switches fail, other HiveAPs in the mesh route around the failure maintaining connectivity. The diagram below shows a wireless LAN functioning without failure, and then the same wireless LAN with multiple failures including an access switch and multiple HiveAPs. The resiliency built in to HiveAPs using the cooperative control protocols allows for the network to seamlessly continue operation even in the event of multiple inline failures. Because there is no central control, there is no worry of a single device that is capable of bringing down an entire wireless network.
Figure 51: High Availability with Seamless Roaming and Automatic Rerouting
Aerohive – New generation WLAN architecture
52
Copyright © 2009, Aerohive Networks, Inc.
FLEXIBLE AUTHENTICATION METHODS HiveAP Radius Server HiveAPs can act as RADIUS authentication servers and respond to 802.1X authentication requests from other HiveAPs acting as RADIUS authenticators (or any other kind of Radius authenticator). A local user database can be created on any HiveAP: -
Used for IEEE 802.1X and for Captive Web Portal Authentication.
-
The local user database is used as a primary or backup user store for the HiveAP RADIUS server for IEEE 802.1X EAP-PEAP, EAP-LEAP, EAP-TTLS, or EAP-TLS authentication.
-
It is highly beneficial for branch or small office deployments that require a local user database.
-
The local user database can also be used as a backup to authentication with Active Directory or any LDAP server. If the Active Directory/LDAP service is unavailable, the local database can automatically be used.
Multiples user authentication solutions Aerohive HiveAPs support several user authentication methods in order to fit with any enterprise requirements (small, medium, large enterprises) and any kind of Wi-Fi users (employees, guests, contractors,...). The diagram hereafter shows the different authentication methods supported by Aerohive.
Figure 52: Multiple user authentication methods
Aerohive – New generation WLAN architecture
53
Copyright © 2009, Aerohive Networks, Inc.
SMARTPOE Powering Wi-Fi access points using Power Over Ethernet (POE) relies on 2 different standards: - Standard POE (802.3af – 15.4 watts) for legacy 802.11a/b/g access points. - POE+ new generation (802.3at – 29 watts), more powerfull, for 802.11n access points requiring more power (due to more antennas, processing,…). Most of legacy wired switches already deployed only support 802.3af and do not provide 802.3at for 802.11n access points. To solve this problem, Aerohive has developped a new technology called SmartPOE™. SmartPOE adapt the power consumption of a HiveAP based on the amount of power it gets from its powering source. This makes migration to 802.11n easier for any legace networks based on standard POE. The table hereafter describes the different scenarios with SmartPOE.
Table 3: Aerohive eases the migration to .11n with Smart PoE, Link Aggregation & Resiliency Note: HiveAP100 series are fully powered using standard POE (802.3af).
Aerohive – New generation WLAN architecture
54
Copyright © 2009, Aerohive Networks, Inc.
CENTRAL MANAGEMENT WITH HIVEMANAGER Centralized configuration, monitoring and reporting is provided by a central network management solution called the HiveManager. This management system can be located anywhere within the network and is not essential to the networks ongoing operation.
Simple and Scalable Management with the HiveManager The HiveManager Network Management System enables simple configuration, OS updates and monitoring of HiveAPs within a cooperative control wireless LAN architecture. Within the cooperative control architecture HiveAPs take care of their own control and data forwarding functions. This leaves the HiveManager with the sole responsibility of managing and monitoring HiveAPs. Even if the HiveManager is powered down and removed from the network, the HiveAPs continue to function and provide their full set of capabilities. Without all the overhead of control and data forwarding that exists in wireless LAN controller-based management solutions, the HiveManager architecture scales to support the management and monitoring of thousands of HiveAPs from a single console. Though each HiveAP can be configured using a robust command line interface, for any more than handful of HiveAPs it is recommended that the HiveManager system is used. HiveManager simplifies the management and monitoring of HiveAPs using a combination of topology views and floor plans, configuration profiles and policies, groups and templates, as well simple bulk configuration of element properties. HiveManager simplifies the provisioning for global policy management and centralized configuration and monitoring by giving the operator a single view into the entire HiveAP network. Benefits Include: - Single management interface for configuration, OS updates, monitoring of thousands of devices. - Real-time topology, performance and user views simplify troubleshooting, capacity planning and security remediation. - Zero configuration HiveAP deployment. - HiveManager is provided as an appliance or as a VM Image to simplify installation. - Non-essential to HiveAP operation HiveManager offers detailed topology views allowing you to drill down to a HiveAP in a particular location, visualize RF energy, monitor the health of the WiFi system and locate rogue access points directly on your floor plan map.
Figure 53: Different views of HiveManager Topology
Aerohive – New generation WLAN architecture
55
Copyright © 2009, Aerohive Networks, Inc.
HiveManager Components and Communication The HiveManager Network Management system is a single entity that can be installed anywhere within a network as long as it has the ability to communicate with the HiveAPs over the network with IP. HiveAPs can even communicate to the HiveManager through NAT (Network Address Translation) or NAPT (Network Address Port Translation), or if there is a firewall blocking any incoming traffic. The HiveManager solution can be configured with two network interfaces, LAN and MGT, to allow the separation of HiveManager administration from the configuration of the HiveAPs, although a single interface for both can be used if desired. Administrators can access the HiveManager graphical interface from a web browser. The interface is based on HTML, AJAX and Flash, allowing administrators to run the HiveManager graphical interface securely and efficiently from any PC. For security reasons, all information is stored on the HiveManager and not on the local PC running the HiveManager GUI. The HiveAPs and HiveManager communicate with each other using the Internet Engineering Task Force (IETF) draft standard protocol for Control and Provisioning of Wireless Access Points (CAPWAP), as well as a set of standard applications including SSHv2, SCP, SNMP, and TFTP. With these protocols and applications, the HiveManager can securely and effectively manage the configurations, monitor logs, and update operating systems of HiveAPs.
Figure 54: HiveManager Components and Communication with HiveAPs
Aerohive – New generation WLAN architecture
56
Copyright © 2009, Aerohive Networks, Inc.
Access profiles The HiveManager supports a very granular access profile configuration. Every screen that can be viewed with in HiveManager can be configured as part of an access profile as either a read only, read/write or disabled completely. Note: Hivemanager supports user name and passwords either locally configured on the HM or via an external RADIUS server.
Figure 55: Granular access profiles for HiveManager administrators
Simplified Configuration Management The management GUI for the HiveManager has been designed so that thousands of HiveAPs can be easily managed and monitored by using profiles and device groups. Profiles are group-related configuration parameters for HiveAPs that can be applied as needed to device groups or selections of individual devices. The HiveManager has profiles for hives, SSIDs, RADIUS, radios, QoS classification and marking, management services, and user profiles. User profiles also define QoS polices, firewall polices, and DNX tunnel settings. Once the profiles are defined, device groups are used to tie them all together. Device groups are a powerful mechanism used to organize and apply configuration to a large number of HiveAPs. Based on a location or a logical deployment type, device groups assign configuration profiles and define mappings from SSIDs to user profiles and VLAN identifiers. By mapping SSIDs, user profiles and VLAN identifiers within a device group, network settings are abstracted from user QoS and firewall policy, allowing the same user profiles to be used across an entire organization, regardless of differences in network topology. Furthermore, if different firewall and QoS policies are required at different locations, new device groups can be created that map the SSIDs to a new set of user profiles and VLANs at these locations. User profiles in different device groups can contain different firewall and QoS policies, but can be defined with the same set of user profile group identifiers as defined in other device groups. This way, as a user moves to new locations, their user profile group identifier ties them to their corresponding user profile at each location. This allows a user’s firewall, QoS, and VLAN settings to dynamically change and follow users wherever they go within the wireless LAN.
Aerohive – New generation WLAN architecture
57
Copyright © 2009, Aerohive Networks, Inc.
Zero Configuration for Wireless Access Point Deployments As HiveAPs are deployed they can be installed without any initial configuration settings. When HiveAPs are powered on and connected to the network using DHCP or DNS, they can automatically learn the information required to contact the HiveManager. HiveAPs then use CAPWAP to contact the HiveManager and identify themselves. Once identified, the HiveManager displays a list of newly discovered HiveAPs. The administrator simply assigns the HiveAPs to device groups, hive profiles and topology maps. From there the HiveAPs inherit configuration settings from the device groups. After that, the administrator can use one button configuration updates to immediately send the configuration to a set of HiveAPs, or schedule the configuration updates for a later time. Likewise, if the operating system requires an update, the administrator can select a set of HiveAPs to immediately send or schedule operating system updates.
Simplified Monitoring and Troubleshooting Along with simplified configuration and OS management, the HiveManager makes it easy to monitor and troubleshoot HiveAPs within a wireless network infrastructure. Using hierarchical map views, an entire set of maps from a world view, down to floor levels, can be imported to organize HiveAPs based on their physical location. Icons can be added to represent locations, buildings, floors, and HiveAPs, and the color of the icons change based on the propagation of alarms from HiveAPs. Either from the topology maps or from filterable and sortable lists of managed HiveAPs, administrators can simply right click on a HiveAP entry to view real time information such as a list of associated wireless clients, logs, roaming information, configurations, and statistics. From HiveManager, administrators can also use tools to ping, view LLDP or CDP information, perform packet captures, and even click a button to SSH directly into HiveAPs for more advanced troubleshooting tasks.
Figure 56: HiveManager Dashboard HiveManager also allows the administrator to view all the active clients in the Wireless LAN, showing their IP addresses, MAC addresses, hostnames, user names (If RADIUS authentication is used), SSIDs, session start times, signal strength values, and the HiveAPs clients that are associated with. This information is stored within the HiveManager and can be exported as a CSV file for advanced troubleshooting and network forensics. For ease of identifying clients, you have the ability to add comments and modify user details for clients which remains persistent across logins. This is especially useful when testing and troubleshooting.
Aerohive – New generation WLAN architecture
58
Copyright © 2009, Aerohive Networks, Inc.
Figure 57: HiveManager Real-time Active Clients Display
Reporting HiveAPs and their main configuration settings, HiveAP neighbor reports, and rogue AP/client information. Administrators can be immediately informed of alarms via configurable email notifications. More detailed information about each client is available by drilling into one of the active clients, including the SSID and APs the clients have been associated with, their signal levels, connection rates, RSSI values, duration, and traffic utilization statistics. Detailed information can be obtained about individual clients, useful for learning about client behavior and looking for dead spots in wireless coverage based on where the clients have been. Many other reports are available in the HiveManager interface, including Radio Statistics, SSID information, Client details, Security Monitoring, Mesh, and even Inventory reports. All are exportable from the HiveManager. Here is a complete list of the currently-available reports: - Summary Overview of APs, Clients, Throughput - Radio Statistics - Channel/Power/Noise - Traffic Metrics - Troubleshooting - SSID Information - Traffic Metrics per SSID - Troubleshooting - Client Details - APs with Most Clients - Client Sessions - Client Radio Mode - Unique Client Count - Client Authentication - Security Monitoring - Rogue APs - Rogue Clients - Mesh Neighbors - Inventory Overview - ...
Aerohive – New generation WLAN architecture
59
Copyright © 2009, Aerohive Networks, Inc.
HIVEMANAGER ONLINE: LESS DOLLARS, MORE SENSE Simpli-Fi Today’s de facto standard controller-based Wi-Fi infrastructure model is just too complicated, too expensive, and too unreliable. It’s common for enterprise and mid-market network operators alike to get caught in a crossroads of compromises involving costs, complexity, features, and reliability. If they choose a consumer-class solution, there aren’t enough features and reliability is a problem, but the interface is simple. If they choose an enterprise-class solution, complexity and cost is a problem, but the platforms are much more feature-rich. If you’ve ever heard of the old adage, “good, fast, cheap: pick two” – it’s somewhat fitting here. In the enterprise, when the Wi-Fi product is user-friendly and inexpensive, it’s typically feature poor, and when the product is feature-rich, it’s often expensive and difficult to use. If you want serious reliability, the solution expense is often doubled. Now you can “pick three” with HiveManager Online (HMOL) from Aerohive Networks. In fact, we’ll throw in another one to sweeten the deal. Those four are ease-of-use, feature-rich, reliability, and inexpensive. HMOL is a cloud-based, disaster-proof wireless network management system (WNMS). If, after the opening sentence, you’re already asking yourself whether HMOL is a software-as-a-service (SaaS) platform, then you’re ahead of the curve. Because HMOL is hosted in and across multiple redundant data centers, it provides inherent high availability for both hardware and data. In today’s überconnected world, being able to access, control, and troubleshoot your Wi-Fi infrastructure from anywhere is not only possible, but essential. Until HMOL, there has been no scalable, inexpensive, and simple method to manage both mid-market and highly-distributed enterprise Wi-Fi networks alike.
Figure 58: HiveManager Online (HMOL) is the Simplest Instantiation of Enterprise Wi-Fi HMOL instantiates the simplest possible implementation of enterprise Wi-Fi, making Aerohive the greenest Wi-Fi infrastructure on the planet. We’ve removed all unnecessary components, such as controllers (whether core, distribution, access, redundant, remote, or otherwise), and the modules, power, cooling, configuration/database backups, rack space in your data center, hardware failures, network bottlenecks, and other costs associated with them. If we were a tree, we’d gladly accept your hug right about now. Additionally, we’ve eliminated those pesky per-AP licenses and per-feature licenses (that go along with primary and backup/failover/clustered controllers). Having less components in the network means: -
Less components to buy (and buy again when you upgrade) Less components to install and configure (time savings) Less components that will break (points of network failure) Less components that must be replaced after their useful lifespan Deployment simplification
Since HMOL lives in the cloud, you can reach it anytime and from anywhere, and since the interface learning curve is extremely short, you’ll be an expert overnight.
Aerohive – New generation WLAN architecture
60
Copyright © 2009, Aerohive Networks, Inc.
It’s also important to note what HMOL is not. HMOL is not a controller, does not house the network control plane as controllers do, and is not required for on-going network operation. HMOL is a network management platform, plain and simple. That is extremely important because with the Aerohive Wi-Fi infrastructure platform, all control and data traffic are handled exclusively by the access points (HiveAPs) allowing unlimited scalability and eliminating bottlenecks, expensive controllers, and latency. HiveAPs handle all aspects of authentication, association, fast/secure roaming, data forwarding, power and channel management, etc. If the Internet pipe goes down, the Wi-Fi stays up, and you can still reach mission-critical network resources such as file servers and printers. A Point of Clarification There’s something we’d like to point out about AP management licensing before someone goes and muddies the water. Controller vendors like to confuse the issue of management costs by saying that the controller is the management platform. If that were true, then they wouldn’t sell Wireless Network Management Systems (WNMS). The controller is only a management device in small networks, but for large enterprise networks, a single controller can no more effectively manage a rack of other controllers than an autonomous AP can manage other autonomous APs. Ever since the market discovered that you can’t manage hundreds or thousands of autonomous APs, there have been WNMS. Once the number of controllers got out of control, WNMS came to the rescue again, but this time managing the controllers instead of the autonomous APs. The majority of Wi-Fi vendors who sell WNMS license it by-the-AP in one way or another. For Aerohive, this could be a CAPEX model like our HiveManager appliance or an OPEX model like HiveManager Online. Unfortunately for the customer, controllers are also licensed in the same way: per-AP. That means that customers pay twice for enterprise management when they buy controller-based solutions. Why twice? First, you pay for the management interface in the controller which scales to a certain point, and then you pay for a WNMS to manage the controllers. Shouldn’t a controller vendor’s WNMS be free if they are going to charge the customer for the management found in controllers? They certainly don’t take the controller-based management aspect out of the cost model when they sell WNMS! Elevator Pitch If all Wi-Fi manufacturers’ APs are competitively-priced and their WNMS is competitively-priced (and they both have to be in order to sell), then how can Aerohive’s solution (without all of the controllerrelated costs) not be significantly less expensive?
Aerohive – New generation WLAN architecture
61
Copyright © 2009, Aerohive Networks, Inc.
Easy and Easier For mid-market organizations with no time or desire to gaze longingly into the eyes of our industryleading feature set, there’s a version called HiveManager Online Express (HMOL Express), which is a full-featured enterprise-class WNMS with a GUI that’s tailored to those who only want to use the basic features of Aerohive’s solution.
Figure 59: HiveManager Online Enterprise (HMOL Enterprise) The guts of the HiveManager Online Enterprise (HMOL Enterprise) platform are still there in HMOL Express, but they’re not staring you in the face when you’re configuring the system for basic connectivity. It’s a case of 0-60 in 4.2 seconds – get it up and running fast. Lest you think we’re honking our own horn a little too loudly, please request a free demo to let us prove that HMOL Express is the cleanest and easiest-to-use GUI the industry. If its coolness makes you smile, ping our twitter page to let us know.
Figure 60: HiveManager Online Express
Aerohive – New generation WLAN architecture
62
Copyright © 2009, Aerohive Networks, Inc.
Most Wi-Fi networks start small and grow, and HMOL can scale linearly starting at a single AP. Instead of the capital expenditure (CAPEX) associated with a data center based management platform, HMOL transitions management of your Wi-Fi infrastructure to an operational expense (OPEX) “pay-as-you-go” model, achieving the lowest startup cost of any Wi-Fi management platform on the market. By moving the management platform into the cloud and out of your data center, you have no management appliance to install or manage, no rack space to build or house, no power consumption, and no cooling to worry about.
Simplification Sweetness HMOL lives in the cloud, and enterprise-wide VPN tunnels (and all of the hardware, software licenses, complexity, and support that often accompany them) are no longer required for secure, remote network management. This is especially important in large distributed enterprises, where there could be thousands of locations. Your Wi-Fi infrastructure can be configured and monitored by multiple administrators who are geographically dispersed, each with appropriate permissions. Streamlining Support The ubiquitous availability of HMOL simplifies and streamlines support to save you time and frustration. Whether you want to upgrade your corporate Wi-Fi network or any number of branch locations, the HiveAP code is already available right on the HMOL platform. You don’t have to go through the motions of logging into a support portal, finding the right code, downloading it, loading it on every AP from a TFTP server, or any of the other previous headaches. You select the code from a drop-down, select the click-boxes beside the APs you want to upgrade, and then click a box to push the code to the APs at one or multiple locations – all over a completely-secure tunnel. Have you ever tried to involve remote support personnel, and they couldn’t access your system without you jumping through all kinds of hoops? Opening a port in the firewall, applying a port redirect, and then setting up remote access software on a PC perhaps? Maybe it was logging into the networking system via console or SSH and grabbing a ‘show tech’ output or setting up GoToMyPC? What a pain. Most of us have been there at one point or another. Instead, what if you could just give support a piece of identifying information and they could, with your permission, login to your system and see the problem for themselves? You wouldn’t have to worry about playing middle-man, and support can both help you and show you what’s going on. It’s yet another advantage of cloud computing.
Dare to Demo Managing large enterprises, distributed enterprises, and mid-market networks alike is simple with HMOL Enterprise. As long as there’s even a tiny Internet pipe at each branch location, you’re ready to roll because management of HiveAPs requires minimal bandwidth.
Figure 61: The Distributed Enterprise with HiveManager Online (HMOL)
Aerohive – New generation WLAN architecture
63
Copyright © 2009, Aerohive Networks, Inc.
Other vendors in the Wi-Fi market have tried several approaches in the distributed enterprise, but thus far, no one has been able to give the customer the desired functionality and simplicity at a reasonable price. Here are a few examples of how not to do it. -
Autonomous APs: no fast/secure roaming support without using PSK, which is a security compromise. A good start, but just not enough if you move beyond a single AP. When it’s a single AP deployment, there’s still often important and useful features missing - like integrated VPN, local authentication (captive web portal, 802.1X/EAP), rogue detection, and much more.
-
Centralized Controllers with Remote APs: very limited functionality, high deployment complexity, often requires local authentication infrastructure, and when the WAN pipe drops, so does even more (and sometimes ALL) functionality. Controller-based vendors realized how much of a mistake this was and quickly moved on to the next option.
-
Controllers and controller-based APs: this is the newest controller-based approach that simply breaks the piggy bank every time. A branch controller for 1-3 APs? Are you kidding? Do the math.
Demo Duo With cooperative control protocols running between HiveAPs, Aerohive achieves the advantages of autonomous APs and controllers without the disadvantages of either. Placing a HiveAP at a branch location is like having a controller and a controller-based AP at each location, but at a fraction of the cost and without any of the configuration complexity. If you would like to see HMOL happen, here are two sweet options: -
HMOL Demo: our wicked cool front-end software will allow you to create your very own HMOL instance in the cloud. Tinker, play, learn, and see what all of the fuss is about. Did we mention the HiveAP simulator function within HMOL? You can simulate a large group of local or remote APs just to see what it might look like in your deployment. If you decide you like what you’ve built, then you can seamlessly move your demo instance to the production system, where you can add real APs.
-
A Product Evaluation or Pilot: there are various options of getting the HiveAPs into your hands in order to demonstrate just how well HMOL works. You can put them through their paces. You’ll be shocked at the power, simplicity, and price.
Serious Security What happens in the cloud stays in the cloud. By that, we mean that you need not worry about security with HMOL. HMOL logins are protected by HTTPS, and HiveAPs connect to your HMOL instance via RFC4347 Datagram Transport Layer Security (DTLS). Since everything under the sun is secured with TLS (Wi-Fi connections, browser and FTP connections, and dozens of others), you don’t have to worry about anyone viewing or interrupting your HiveAP-to-HMOL traffic. The “Datagram” part of DTLS is the clue that indicates the use of UDP for the CAPWAP connection between HiveAPs and HMOL. Here’s a cool picture.
Figure 62: CAPWAP secured with DTLS
Aerohive – New generation WLAN architecture
64
Copyright © 2009, Aerohive Networks, Inc.
Organizations often implement policies specifying that some administrators should be allowed make changes to the system while others may only monitor the system. With HMOL, you can assign individual system permissions to each user or group of users.
Figure 63: Group or Individual Administrative Permissions Aerohive’s HiveAPs support all of today’s standards-based wireless security protocols plus a rolebased firewall, IPSec VPN client and server functionality, and intrusion detection – just to name a few. With Aerohive’s distributed control and data planes, security is implemented at the edge, for maximum security.
Gold Lining at Silver Lining Prices Customers often find themselves paying for resources they aren’t using, and may never use. Controllers introduce a stair-stepped cost model where the customer must buy not only the controller, but also “blocks” of AP and/or feature licenses.
Figure 64: Controllers cause stair-stepped cost Just for the sake of argument, suppose that a Wi-Fi infrastructure vendor sells two controllers: a smallish controller with a 6-AP license and a larger controller with license block options of 12, 25, 50, and 100. When even simple Wi-Fi requirements are needed, such as radio resource management and fast/secure roaming, a controller must be introduced. Let’s look at the problem this causes.
Aerohive – New generation WLAN architecture
65
Copyright © 2009, Aerohive Networks, Inc.
Micro Case Studies -
Case 1: when the customer needs 3 APs, they must pay for 6 APs plus the controller hardware and feature licenses. Even though they have now over-paid for the solution, they still usually don’t receive a full array of features available in the controller. For that, they must pay a per-AP feature license as well.
-
Case 2: when the customer needs 7 APs, the controller vendor introduces a significant price increase in the form of the larger controller hardware. Then of course follows the 12-AP license (5 of which aren’t used) and those same per-AP feature licenses.
Keep in mind that we’ve used small scale numbers to illustrate a concept, but the concept applies even more to a large enterprise. Instead of paying for 5 APs they’re not using, the customer could be paying licensing for hundreds of APs they’re not using. With HMOL, licensing is per-AP/year with no up-front costs. Sign up online for HMOL, buy the HiveAPs appropriate for your network, done. If you can find any extraneous components to this solution, drop us a note – we’ll take them out. Our prime directive is to Simpli-Fi.
Figure 65: For Those Who Like Pictures
Aerohive – New generation WLAN architecture
66
Copyright © 2009, Aerohive Networks, Inc.
Less Stuff Means Less Money HMOL’s linear, pay-as-you-grow model is the perfect cost-conscience replacement for the pay-morenow, controller-based model that is so prevalent today. We’re sure you’ll find some other projects on which to spend that left-over IT budget money. If not, please consider donations to www.aerohive.com/beer_fund. Let’s recap Aerohive’s differentiation with a simple chart.
Table 4: WLAN Component Comparison Chart There’s always hype around the cost of APs, but in the big scheme of many of today’s enterprise WiFi infrastructures, APs are only one part. When it’s all said and done, you have to look at the solution cost. One simple way to do that is to take the total solution cost and divide it by the number of APs. That gives you a per-AP solution cost that allows you to compare across vendors. It takes the marketing and pricing confusion out of the equation and allows for a simple apples-to-apples comparison. Do it. Dare to compare.
Conclusion HiveManager Online is the first cloud-based, enterprise-class Wi-Fi management solution and is a breakthrough in management simplicity, flexibility, and redundancy. HMOL gives financial control back to organizations by offering a linearly-scalable Wi-Fi infrastructure management platform with no up-front management costs. Combined with HiveAPs, it’s the simplest instantiation of enterprise WiFi possible. Because it’s web-based, giving HMOL a try is as simple as filling out a web form and logging into your own HMOL instance. The only question remaining is whether you’ll choose HMOL Express or HMOL Enterprise. You decide. www.aerohive.com/register
Aerohive – New generation WLAN architecture
67
Copyright © 2009, Aerohive Networks, Inc.
CONCLUSION The continued migration away from autonomous access points, the evolution of wireless networks to support mission-critical/real-time applications and the imminent arrival of 802.11n will demand an architecture that provides enterprise wireless LAN infrastructures that are easier to deploy and expand, lower cost, more reliable, more scalable, higher performing and more suitable for voice-overwireless LAN than previous generations of wireless LANs. That next generation wireless LAN architecture is a cooperative control architecture. -----
Aerohive – New generation WLAN architecture
68
