The NeTraMet Meter

 NeTraMet, a meter for network traffic flows, is the first implementation of the architecture. It is available as public domain software with source code and has been successfully compiled on Solaris, SunOS, Irix and Linux. Under UNIX, the meter is using the libpcap BSD packet capturing library. A meter implementation on the PC (MS-DOS based) is also available. This implementation uses the CRYNWYR packet drivers for access to the networking hardware.

The roots of NeTraMet were not in traffic analysis, in the beginning it was developed for traffic accounting. Currently one Sun SPARC Workstation with NeTraMet is used for the traffic accounting of all IP traffic in New Zealands academic networks. The participiants in the New Zealand networks are charged fees based on the traffic measurements made with NeTraMet. The system has been in use for some years now and has shown to be a stable and suitable solution for this kind of measurement problem.

The meter could simply establish flows for every possible combination of source and destination attributes it observes (like the Cisco Switch does) but this would need a lot of memory. Instead the NeTraMet meter uses a set of rules to decide which flows are of interest. Those rules can also be set up in a way so that particular kinds of packets are totally ignored.

This is the main conceptual advantage that NeTraMet offers. It allows the use of freely parametrizable flow specifications for measurement, just as proposed by the model presented in chapter 2. For this purpose, so called "rulesets" can be defined that specify for which parameters the measurement is to be done. Those parameters could be adresses (of different layers), ports, or anything that one can imagine to categorize data from one flow against the others.

For the definition of traffic flow specifications, NeTraMet distinguishes the address attributes of a host by the following three kinds:

Adjacent

On a standard ethernet this would be an ethernet MAC address. For other media, the decoding of addresses has not yet been implemented.

Peer

A peer address can be an IP address, a DECnet phase IV address, a Novell network number, an EtherTalk address or a CLNS NSAP, these being the five protocols currently understood by NeTraMet.

Transport

A transport address contains specifications for details within the peer protocol. For IP these are the protocol type and source and destination port numbers, and similar kinds of detail are defined for the other protocols.

This abstract definition of the flow endpoint granularities has the advantage that the RTFM architecture is easily extendable to new protocols. For example, the NeTraMet meter currently does not support the decoding of IPv6 or encapsulated IP. Nevertheless, implementing those protocols is possible within the architecture, so the only thing that has to be extended in order to support those protocols will be the applications.

Figure 3.3 shows how the abstract layers would correspond to transport, internetwork and network technology layer when the meter is used in a TCP/IP environment.

  

Figure 3.3: Different Layers NeTraMet can use for Flow Endpoints

Within the meter a flow is implemented as a data structure containing the attributes of its source and destination, its packet and byte counters, the times it was first and last observed, and other information used for control purposes.

This data structure is called a ``flowDataEntry'' node in the MIB. These entries are stored in a table under the OID

.iso.org.dod.internet.mgmt.mib-2.flowMIB.flowData.flowDataTable.

Table 3.1 shows the fields that are defined for each flow in those flow records. One of those records is allocated for each flow the meter captures. The records are stored in the ``flowDataTable''. The location of this table and the records in the flowMIB can be seen in figure B.1.

In order to reduce the transfer time from the meter to the reader, the flow table itself can be transferred from the NeTraMet meter in a BER encoded packaged form with SNMPv2 GETBULK requests. Additionally, it is possible to read the entries in an unencoded form using standard SNMP GET requests.

810

 

1 flowDataIndex Integer32 INTEGER (-2147483648..2147483647)

2 flowDataTimeMark TimeFilter INTEGER (0..4294967295)

3 flowDataStatus INTEGER

4 flowDataSourceInterface Integer32 INTEGER (-2147483648..2147483647)

5 flowDataSourceAdjacentType AdjacentType INTEGER

6 flowDataSourceAdjacentAddress AdjacentAddress OCTET STRING [3..20]

7 flowDataSourceAdjacentMask AdjacentAddress OCTET STRING [3..20]

8 flowDataSourcePeerType PeerType INTEGER

9 flowDataSourcePeerAddress PeerAddress OCTET STRING [3..20]

10 flowDataSourcePeerMask PeerAddress OCTET STRING [3..20]

11 flowDataSourceTransType TransportType INTEGER (1..255)

12 flowDataSourceTransAddress TransportAddress OCTET STRING (2)

13 flowDataSourceTransMask TransportAddress OCTET STRING (2)

14 flowDataDestInterface Integer32 INTEGER (-2147483648..2147483647)

15 flowDataDestAdjacentType AdjacentType INTEGER

16 flowDataDestAdjacentAddress AdjacentAddress OCTET STRING [3..20]

17 flowDataDestAdjacentMask AdjacentAddress OCTET STRING [3..20]

18 flowDataDestPeerType PeerType INTEGER

19 flowDataDestPeerAddress PeerAddress OCTET STRING [3..20]

20 flowDataDestPeerMask PeerAddress OCTET STRING [3..20]

21 flowDataDestTransType TransportType INTEGER (1..255)

22 flowDataDestTransAddress TransportAddress OCTET STRING (2)

23 flowDataDestTransMask TransportAddress OCTET STRING (2)

24 flowDataPDUScale INTEGER

25 flowDataOctetScale INTEGER

26 flowDataRuleSet INTEGER

27 flowDataToOctets Counter64 INTEGER (0..18446744073709551615)

28 flowDataToPDUs Counter64 INTEGER (0..18446744073709551615)

29 flowDataFromOctets Counter64 INTEGER (0..18446744073709551615)

30 flowDataFromPDUs Counter64 INTEGER (0..18446744073709551615)

31 flowDataFirstTime TimeStamp INTEGER (0..4294967295)

32 flowDataLastActiveTime TimeStamp INTEGER (0..4294967295)

33 flowDataSourceSubscriberID OCTET STRING

34 flowDataDestSubscriberID OCTET STRING

35 flowDataSessionID OCTET STRING

36 flowDataSourceClass INTEGER

37 flowDataDestClass INTEGER

38 flowDataClass INTEGER

39 flowDataSourceKind INTEGER

40 flowDataDestKind INTEGER

41 flowDataKind INTEGER

Figure 3.4 shows how the times are defined for traffic flows captured by a NeTraMet meter. All times are measured relative to the uptime of the meter. Therefore, a meter reader will have to read the current uptime of the meter as well as all relevant time information for each of the flows that is to be analyzed. The two graphs depict the state of the same flow record, the second one showing the state a short time after the first. As it can be seen from the graph, additional packets have been received between the two queries.

For the ``flow timeout'' NeTraMet uses a default value of 600 seconds (the flowInactivityTimeout parameter in the MIB [4]). This value can be modified by meter managers by doing a SET operation on

flowMIB.flowControl.flowInactivityTimeout.

A flow that is not yet expired (i.e. for which the flow timeout has not yet been exceeded without the reception of a packet) has got the flowDataStatus ``current'' (2). A flow for which no more data has been seen is ``inactive'' (1).

  

Figure 3.4: Flow Time Definitions with NeTraMet

When reading the flow data from the meter, one has to take care about the time skew that can occur during the query. For example if the meter reader would first read the meter uptime and then transfer the flow records for all flows it is interested in, it can happen that ``LastActiveTime'' values are seen that are in the future. When doing calculations with those times, this has to be kept in mind.