THE LOW-DOWN ON CONTROLLER-BASED WI-FI ACCESS POINTS

At a recent internal discussion forum, the question was asked about what types of information access points might send back to controllers, and what control, spectrum or telemetry data Wi-Fi clients might send to APs or controllers. After some consideration, I thought I would share my response to this with the broader ICT community through our Technology Update.

The controller-based Wi-Fi access points that conform to standards do so by complying with IEEE standards (the IEEE802.11 series) and/or IETF RFCs (requests for comment), of which there are thousands. As a side note, IETF also maintain a much smaller set of BCPs (best common practices) which are recommendations on the ‘best’ method to implement particular scenarios. For example, BCP-38 defines the best way to protect against RFC-1918 IP address spoofing … however, I digress.

The standard for Wi-Fi control is RFC 5415. This RFC defines a protocol named CAPWAP (Control and Provisioning of Wireless Access Points) and was developed jointly by people from Research in Motion (the Blackberry company), Aruba Networks and Cisco Systems.

The question raised was specifically in terms of controller-based Wi-Fi environments. There is no standardised interaction between Wi-Fi clients and controllers, although Cisco makes use of telemetry from APs to direct clients to or away from specific situations, and some such telemetry is generated as a by-product of reception of traffic from clients. The types of situations some Cisco equipment can detect or prevent includes:

• Detection of rogue devices within the defined ISM band channels
• Detection of non IEEE 802.11 radiators over the defined ISM band channels (items might include: microwave oven, DECT cordless phone, RADAR system radiation, radio-therapy medical equipment etc)

Passively the controller, populated with geographic knowledge gained from supplied heat maps and floor plans, is able to determine the optimal channel selection for specific APs so as to avoid other APs or foreign radiators, which in turn will affect such control by directing APs to specific channels through CAPWAP control messages.

Active control is also affected in environments where sufficient hardware exists that selected hardware can be dedicated to monitoring functions for control purposes. Instrumented again using CAPWAP, specific APs can be used to block specific channels in specified geographic areas, thus preventing other APs or clients from attempting to use a channel known to be compromised.

There are a number of proposed updates and extensions to the IEEE802.11 standards being driven in part by the introduction of 802.11n and more recent advances. These extensions include the ability to generate Channel Scan Reports and Neighbour Reports at the AP, and then use CAPWAP to return these reports to the controller. Vendors at present use their own methods to generate similar capability, pending standardisation of these capabilities. Using Cisco as an example, currently some AP models have an off-channel listen mode which is typically invoked briefly every 60 seconds – a balance between serving clients working on the channel and discovering what else is out there.

Some AP models have the ability to monitor on-channel between packets, gathering data that can be used for “environment intelligence”. The Cisco ‘Clean Air‘ feature can take this further, dedicating some hardware to the monitoring function. Ultimately, the controller combines all these information feeds to determine an optimal channel plan and achieve maximised throughput over the available channels. Juniper’s ‘Active and Passive scanning‘ has the AP pause the channel using the CTS mechanism, but cleverly “CTS-to-self”, to briefly listen off-channel; other vendors have similar functionality.

Returning to CAPWAP and ignoring Flex Connect in Cisco’s case, traffic from clients is encapsulated at the AP and forwarded to the controller for routing or subsequent processing. The standard defines this encapsulation as GRE (generic routing encapsulation) RFC-2784. Section 4 of CAPWAP RFC-5416, “CAPWAP Protocol Binding for IEEE 802.11”, defines the mandatory frame information field where the AP is required to add RSSI, SNR and client data rate of the received radio frame into the header of the encapsulated frame being forwarded to the controller, for every frame.

From these sources, the controller is able to build a detailed picture of:

• Which APs can receive from other APs;
• At what power levels they can receive from other APs;
• The physical locations of APs (some APs have GPS receivers and include the location in the report);
• Client-AP proximities with received power levels; and
• Known external radiators with general location data.

Therefore through a controller management interface it is possible to see all the clients of all the APs and all the known SSIDs (including APs and clients of foreign networks with broadcast SSID or “guest” mode) with near real-time received power levels.

In summary, there is no standards-defined communications between Wi-Fi client and controller (the client will never be aware that the associated AP is operating under CAPWAP control), however there is well defined messaging between the AP and controller. Vendors have subsequently developed ways to take advantage of this information to facilitate additional, proprietary, features, such as the Cisco “Clean Air” feature.

You may like to read up on other WI-FI and related RFCs, some of which can be found at:

THE LOW-DOWN ON CONTROLLER-BASED WI-FI ACCESS POINTS

Filter by tag