We are delighted to announce the much-anticipated release of Noction Flow Analyzer (NFA)...
Usage-based billing enables customers to pay only for data that they have used. In order to charge customers based on data usage, a company must have a good metering system in place. The system must be able to provide accurate information on the volume of traffic transmitted and received by each customer. The metering system should be able to convert data usage to readable billing information which is sent to a billing system for invoice creation.
There are several protocols available that the metering system can use to accurately measure data usage. Examples are SNMP, Netflow or sFlow. Each protocol has its advantages and disadvantages which the provider must carefully consider to be able to perform accurate billing. For example, traditional SNMP may be more convenient to measure data consumption, but it lacks information about the source and destination of the transmission. SNMP only reports the total amount of traffic. While this is a perfect choice for billing when the entire port is assigned to a customer, it cannot be used for accurate billing if customers share the same port.
Itemized Billing with sFlow/NetFlow
Unlike SNMP, NetFlow and sFlow collect information about the source and destination involved with the traffic, application, volume of traffic, etc. Because customers may require a more granular view of traffic usage, the metering system should support NetFlow/sFlow to provide itemized billing reports. As a result, customers are confident that the reports reflect the exact use of data. In addition, they can better control costs in the future as reports contain detailed breakdown of data usage, e.g based on VLAN, priority, type of service, etc. In addition to sFlow, which provides full layer 2 – 7 traffic visibility, we can also use NetFlow to report the various traffic attributes required for itemized billing. More specifically, Flexible NetFlow v9 allows to match or collect the following attributes:
- IP protocol
- Type of service
- IPv4/IPv6 source and destination addresses
- TCP/UDP source and destination ports
- BGP origin/destination and peer ASs
- MPLS TOP
- Layer 2 information such as source/destination MAC addresses, Vlan IDs
- Flow direction
- Replication factor and number of replicated packets/bytes for multicast traffic
So, should one use NetFlow or sFlow for usage-based billing? Before answering this question, let’s summarize key facts about sFlow and NetFlow.
The Accuracy of sFlow Measurement
Sampled flow (sFlow) is a packet sampling protocol that captures packet headers and partial packet payload (the first 64 or 128 Bytes) into sFlow datagrams. A device with an enabled sFlow has no cache to temporarily store datagrams. Immediately after sampling, samples are forwarded to sFlow collectors. sFlow datagrams can carry multiple samples. sFlow provides full layer 2 – 7 traffic visibility since the entire packet headers are captured. This allows reporting MAC, VLAN, and application information along with L3 – L4 attributes, typically reported by NetFlow.
Unlike NetFlow, sFlow does not support the unsampled mode. Individual packets are randomly sampled based on the defined sampling rate; an average 1 out of N packets is randomly sampled. This type of sampling does not provide a 100% accurate result, but it does provide a result with quantifiable accuracy . The accuracy of sFlow measurement is therefore dependent on the number of samples. If the variable N is set too high, sFlow records generated from the samples may be less representative of the actual traffic. Moreover, some low volume flows may not be counted at all, especially if the traffic time window is short. Increasing a sampling rate thus lowering the variable N seems to be a solution to this problem. However, while increasing the sampling rate improves the accuracy of sFlow measurement, more sFlow transmissions are generated that are sent over the network to the sFlow collector. In the worst case, the collector may be completely overwhelmed by the traffic. The sampling rate is therefore always a compromise between scalability and accuracy and should reflect the interface speed and the traffic volume. For example, the proposed sampling rate that works for most networks is 1 in 1000 for the 1000Mb/s link and 1 in 2000 for the 10Gb/s link .
The graph in Figure 1 is useful for determining the number of samples that should be collected to obtain a given % error . This can then be used to determine the sampling rate. The relative sampling error is less than 2.5% when the number of samples in class is 10000. The accuracy of sFlow results may be further improved with monitoring over a longer period of time.