





sFlow.org                                                    Peter Phaal
http://www.sFlow.org/                                        InMon Corp.
info@sflow.org

                                                               Jim Wendt
                                                         Hewlett-Packard

                                                              April 2007


                        sFlow 802.11 Structures



Copyright Notice

Copyright (C) sFlow.org (2007). All Rights Reserved.

Abstract

This memo describes sFlow version 5 structures for exporting 802.11
related data.

Table of Contents

1. Overview ......................................................  1
2. Reference Model ...............................................  1
3. sFlow Datagram Extensions .....................................  3
4. References ....................................................  7
5. Author's Addresses ............................................  7

1. Overview
   This document describes additional structures that allow an sFlow
   agent to export additional information about the 802.11 traffic.
   sFlow version 5 is an extensible protocol that allows the addition of
   new data structures without impacting existing collectors. This
   document does not change the sFlow version 5 protocol [1], it simply
   defines additional, optional, data structures that an 802.11 device
   [2] can use when reporting on 802.11 traffic. An sFlow collector that
   does not understand a particular structure should simply skip it.

2. Reference Model
   The figure below shows the basic elements of an 802.11 wireless
   access point (WAP).  In this abstract model a WAP is simply a device
   that contains 1 or more radios.






v1.00                           sFlow.org                       [Page 1]

Version 1                sFlow 802.11 Structures              April 2007


   +------------------------------------+
   |   +-------+            +-------+   |
   |   | ETH 1 |    ...     | ETH N |   |
   |   +-------+            +-------+   |
   |                                    |
   |       Wireless Access Point        |
   |                                    |
   |  +---------+          +---------+  |
   |  | RADIO 1 |   ...    | RADIO N |  |
   |  +---------+          +---------+  |
   +------------------------------------+

   Wired interfaces are indicated as ETH 1 .. ETH N. Wireless interfaces
   are indicated at RADIO 1 .. RADIO N.

   There are a number of possible packet flows through a WAP:

   o A packet is received on a wired interface and sent on a wireless
     interface.

   o A packet is received on a wired interface and sent on a wired
     interface.

   o A packet is received on a wired interface and sent on the same
     interface (only possible if the WAP is performing a routing func-
     tion).

   o A packet is received on a wired interface and discarded.

   o A packet for the WAP management entity is received on a wired
     interface.

   o A packet is received on a wireless interface and send on a wired
     interface.

   o A packet is received on a wireless interface and sent on another
     wireless interface.

   o A packet is received on a wireless interface and sent on the same
     interface.

   o A packet is received on a wireless interface and discarded.

   o A packet for the WAP management entity is received on a wireless
     interface.

   Packet flows between wired interfaces are switched or routed and can
   be described using existing sFlow data structures.



v1.00                           sFlow.org                       [Page 2]

Version 1                sFlow 802.11 Structures              April 2007


   Packet flows that pass through one or more radios require additional
   information in the sFlow structures to fully describe them. In
   addition there are counters specific to the radios that require
   additional sFlow structures if they are to be exported.

   Note: The sFlow specification required that "each sFlow Instance must
   ensure that any packet observed at a Data Source has an equal chance
   of being sampled, irrespective of the Packet Flow(s) to which it
   belongs."  When a WAP is performing meshing or repeating functions it
   is possible that many frames will be received and resent on the same
   radio. An sFlow instance must ensure that these frames are considered
   only once as sampling candidates even if ingress and egress sampling
   is being performed on the radio.

   A radio may be used off-channel to monitor traffic associated with
   nearby 802.11 devices. It can be useful to monitor this off-channel
   traffic via sFlow, however, packets received in this manner should be
   marked as discarded since they are not part of the traffic associated
   with the WAP. The sFlow Instance associated with a radio must only
   sample on-channel packets unless it has been explicitly configured to
   also sample off-channel packets.  The mechanism for configuring
   channel scanning behavior and sampling is out of scope for this
   document.

3. sFlow Datagram Extensions

   The sFlow Datagram format describes the basic structure of flow and
   counter samples. Part of the specification is a list of "reason
   codes" for discarded packets. It is useful define an additional
   reason code for WAPs in order to identify packets that may have been
   received as part of a passive scan.  This same code could be used in
   situations where any network interface (not just a wireless
   interface) is operating promiscuously and capturing packets that are
   not part of communication to or through the capturing device.

   263 = promiscuously received packet not intended for this device

   In addition, the following new structures are defined that allow
   captured 802.11 frames to be exported (along with extended flow
   information about the radio interfaces) and additional counters:

/* Additional packet header types for enum header_protocol */

   IEEE80211MAC             = 15  /* 802.11 MAC */
   IEEE80211-AMPDU          = 16  /* 802.11n Aggregated MPDU (A-MPDU)
                                     starting with MPDU delimiter */
   IEEE80211-AMSDU-Subframe = 17  /* MSDU transported in A-MSDU starting
                                     with A-MSDU subframe header */



v1.00                           sFlow.org                       [Page 3]

Version 1                sFlow 802.11 Structures              April 2007


/* The 4-byte cipher_suite identifier follows the format of the cipher suite
   selector value from the 802.11i (TKIP/CCMP amendment to 802.11i)
   The most significant three bytes contain the OUI and the least significant
   byte contains the Suite Type.

   The currently assigned values are:

   OUI        |Suite type  |Meaning
   ----------------------------------------------------
   00-0F-AC   | 0          | Use group cipher suite
   00-0F-AC   | 1          | WEP-40
   00-0F-AC   | 2          | TKIP
   00-0F-AC   | 3          | Reserved
   00-0F-AC   | 4          | CCMP
   00-0F-AC   | 5          | WEP-104
   00-0F-AC   | 6-255      | Reserved
   Vendor OUI | Other      | Vendor specific
   Other      | Any        | Reserved
   ----------------------------------------------------
*/
typedef unsigned int cipher_suite;

/* Extended 80211 Payload
   Used to provide unencrypted version of 802.11 MAC data. If the
   MAC data is not encrypted then the agent must not include an
   extended_80211_payload structure.
   If 802.11 MAC data is encrypted then the sampled_header structure
   should only contain the MAC header (since encrypted data cannot
   be decoded by the sFlow receiver). If the sFlow agent has access to
   the unencrypted payload, it should add an extended_80211_payload
   structure containing the unencrypted data bytes from the sampled
   packet header, starting at the beginning of the 802.2 LLC and not
   including any trailing encryption footers.  */
/* opaque = flow_data; enterprise = 0; format = 1013 */

struct extended_80211_payload {
   cipher_suite ciphersuite; /* encryption scheme used for this packet */
   opaque       data<>;      /* unencrypted bytes from the payload */
}

/* Extended 802.11 Data
   Note: in situations where an 802.11 packet is received and resent
         wirelessly it is possible to have two extended_80211
         elements associated with the flow sample, one for the
         receiver and one for the transmitter */

enum ieee80211_version {
  a = 1,



v1.00                           sFlow.org                       [Page 4]

Version 1                sFlow 802.11 Structures              April 2007


  b = 2,
  g = 3,
  n = 4,
}

typedef unsigned int duration_us; /* Duration measured in microseconds
                                     0 = unknown */

/* opaque = flow_data; enterprise = 0; format = 1014 */

struct extended_80211_rx {
   string ssid<32>;            /* SSID string */
   mac  bssid;                 /* BSSID */
   ieee80211_version version;  /* version */
   unsigned int channel;       /* channel number */
   unsigned hyper speed;
   unsigned int rsni;          /* received signal to noise ratio,
                                  see dot11FrameRprtRSNI */
   unsigned int rcpi;          /* received channel power,
                                  see dot11FrameRprtLastRCPI */
   duration_us packet_duration /* amount of time that the successfully
                                  received packet occupied the RF medium. */
}

/* opaque = flow_data; enterprise = 0; format = 1015 */

struct extended_80211_tx {
   string ssid<32>;              /* SSID string */
   mac  bssid;                   /* BSSID */
   ieee80211_version version;    /* version */
   unsigned int transmissions;   /* number of transmissions for sampled
                                    packet.
                                    0 = unkown
                                    1 = packet was successfully transmitted
                                        on first attempt
                                    n > 1 = n - 1 retransmissions */
   duration_us packet_duration;  /* amount of time that the successfully
                                    transmitted packet occupied the
                                    RF medium */
   duration_us retrans_duration; /* amount of time that failed transmission
                                    attempts occupied the RF medium */
   unsigned int channel;         /* channel number */
   unsigned hyper speed;
   unsigned int power;           /* transmit power in mW. */
}

/* Extended 802.11 Aggregation Data */
/* A flow_sample of an aggregated frame would consist of a packet



v1.00                           sFlow.org                       [Page 5]

Version 1                sFlow 802.11 Structures              April 2007


   header for the whole frame + any other extended structures that
   apply (e.g. 80211_tx/rx etc.) + an extended_80211_aggregation
   structure which would contain an array of pdu structures (one
   for each PDU in the aggregate). A pdu is simply an array of
   flow records, in the simplest case a packet header for each PDU,
   but extended structures could be included as well. */

struct pdu {
   flow_record flow_records<>;  /* Flow records for each of the PDUs
                                   in the aggregation */
}

/* opaque = flow_data; enterprise = 0; format = 1016 */

struct extended_80211_aggregation {
   pdu pdus<>;
}

/* IEEE802.11 interface counters - see IEEE802dot11-MIB */
/* opaque = counter_data; enterprise = 0; format = 6 */

struct ieee80211_counters {
   unsigned int dot11TransmittedFragmentCount;
   unsigned int dot11MulticastTransmittedFrameCount;
   unsigned int dot11FailedCount;
   unsigned int dot11RetryCount;
   unsigned int dot11MultipleRetryCount;
   unsigned int dot11FrameDuplicateCount;
   unsigned int dot11RTSSuccessCount;
   unsigned int dot11RTSFailureCount;
   unsigned int dot11ACKFailureCount;
   unsigned int dot11ReceivedFragmentCount;
   unsigned int dot11MulticastReceivedFrameCount;
   unsigned int dot11FCSErrorCount;
   unsigned int dot11TransmittedFrameCount;
   unsigned int dot11WEPUndecryptableCount;
   unsigned int dot11QoSDiscardedFragmentCount;
   unsigned int dot11AssociatedStationCount;
   unsigned int dot11QoSCFPollsReceivedCount;
   unsigned int dot11QoSCFPollsUnusedCount;
   unsigned int dot11QoSCFPollsUnusableCount;
   unsigned int dot11QoSCFPollsLostCount;
}

/* 802.11 radio utilization
   Utilization can be computed based on the three counters: elapsed_time,
   counts total time, on_channel_time counts the time spent
   on the radio's assigned channel (this may be less than elapsed_time



v1.00                           sFlow.org                       [Page 6]

Version 1                sFlow 802.11 Structures              April 2007


   if the radio spends time performing off-channel scans), and
   on_channel_busy_time counts the time spent sending and receiving frames
   as part of on-channel activity. */
/* opaque = counter_data; enterprise = 0; format = 1002 */

struct radio_utilization {
   unsigned int elapsed_time;         /* elapsed time in ms */
   unsigned int on_channel_time;      /* time in ms spent on channel */
   unsigned int on_channel_busy_time; /* time in ms spent on channel
                                         and busy */
}

4. References

[1]  Phaal, P. and Lavine, M., "sFlow Version 5",
     http://www.sflow.org/sflow_version_5.txt, July 2006

[2]  IEEE 802.11, "Part 11: Wireless LAN Medium Access Control (MAC) and
     Phyical Layer (PHY) Specification", 1999

[3]  IEEE 802.11i, "Part 11: Amendment 6: Medium Access Control Security
     Enhancements", 2004

5. Author's Address

   Peter Phaal
   InMon Corp.
   580 California Street, 5th Floor
   San Francisco, CA 94104

   Phone: (415) 283-3263
   EMail: peter.phaal@inmon.com

   Jim Wendt
   Hewlett-Packard
   8000 Foothills Blvd., MS 5555
   Roseville, CA 95747

   Phone: (916) 785-5198
   EMail: jim.wendt@hp.com











v1.00                           sFlow.org                       [Page 7]

