Implementing sFlow in 802.11 WLAN device

From: Peter Phaal <peter.phaal@inmon.com>
Date: 07/20/05
Message-Id: <200507201852.j6KIqTwu003778@zeus.inmon.com>

There has been quite a bit of interest in applying sFlow monitoring to
wireless networks. I thought this might be a good topic for the mailing
list.

 

Here are some initial thoughts on implementating an sFlow agent in a
wireless access point (WAP). Firstly, it seems like it should be relatively
straightforward to implement since 802.11 devices generally have low port
counts, operate at low speeds and have a general purpose microprocessors
implementing their forwarding and management functions. A good starting
point for an implementation would be the source code at:

http://www.sflow.org/developers/tools.php

 

A typical WAP has two interfaces, a wired 802.3 interface, and a wireless
802.11 interface. Suppose that the wireless access point supports SNMP and
has implemented the mib-2 ifTable and that the following interfaces are
defined:

ifIndex=1, the wired 802.3 interface

ifIndex=2, the agent loopback interface

ifIndex=3, the wireless 802.11 interface

 

The sFlow agent embedded in the WAP would periodically send the ifTable
counter values for each of these interfaces as if_counters structures. Since
ifIndex 1 is an 802.3 interface, it could also send ethernet_counters for
this interface. Since these counters are all maintained as part of a
standard SNMP implementation it would be straightforward to export them
using sFlow.

 

Improved visibility can be achieved by defining a new 802.11 sFlow counter
structure, the sFlow agent would export these counters in addition to the
base interface counter set. It would share many attributes in common with
the ethernet_counters block since 802.11 uses CSMA/CA access control and
counts of collisions etc would be useful. In addition the current radio
channel, SSID, and counts of wireless association activity, control
messages, beacons etc would be useful. Defining a standard sFlow.org
structure would be a worthwhile as it will ensure interoperability between
WAPs and wide support among sFlow application developers. If anyone has
suggestions for a standard "counter set" for an 802.11 interface, please
post to the mailing list.

 

Packet flow sampling can be done in software on the WAP, providing
ingress/egress sampling on both the wired and wireless interfaces. Sampling
of on the wireless interface should be performed on unencrypted frames. The
packet paths of interest are as follows:

1. samples of packets received on the wired interface and sent on the
wireless interface would be reported as sFlow flow samples with input
ifIndex=1 and output ifIndex=3.
2. samples of packets received on the wireless interface and sent on
the wired interface would have input ifIndex=3 and output ifIndex=1.
3. samples of packets relayed by the wireless interface would have both
source and destination ifIndex=3.
4. any control or management packets would have the agent loopback
interface, ifIndex=2, as the source or destination.

 

Currently the sFlow header_protocol enumerated type doesn't have an entry
for 802.11. To allow for the export raw 802.11 headers, I propose the
addition of the following entry to the header_protocol enumerated type:

IEEE80211 = 15,

An IEEE80211 header would start at the PLCP field in the header. The
trailing CRC must not be included, but the CRC octets will be counted in the
stripped count for the sample. The PLCP field provides useful information
about the speed of connection to each host associated with the WAP. This
would be very useful for capacity planning.

 

It could be useful to add an additional extended_80211 flow structure to
captured 802.11 frames. This structure could include the MAC address of
another WAP if the frame is being relayed, signal strength etc.

 

To conclude, with the simple addition of the IEEE80211 header_protocol it is
possible to implement an sFlow agent on a WAP that would provide clear
visibility into traffic on the wireless network. sFlow version 5 is easily
extensible and the addition of additional extended flow and counter
information could provide useful additional functionality.

 

Peter
Received on Wed Jul 20 11:52:35 2005

This archive was generated by hypermail 2.1.8 : 07/20/05 PDT