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]