De criterios superpuestos: la preocupación por los bancos vacíos.

In 1995, the Real-time Traffic Flow Measurement (RTFM) working group was established within the IETF to produce a deployable flow measurement system that would enable real- time traffic data reduction and would minimise the size of captured measurements. The resulting RTFM traffic measurement architecture [BrMR99] consists of three main network entities and a fourth less integral part, as shown in Figure 2-12. In this context, traffic flows are considered to be arbitrary groupings of packets defined by the attributes of their endpoints, which can be a complete five-tuple (source and destination IP address, transport protocol, source and destination port numbers), a pair of net-blocks, or two lists of net-blocks [BrMu01].

Figure 2-12: The RTFM Architecture

The meters are the main entity of the traffic measurement model. They observe packets at a single point in the network and classify them into certain groups (flows), for (each of) which they then accumulate certain attributes. Within RTFM, flows are bi-directional and for each flow two sets of counters are maintained, one for each direction. The three general types of flows’ attributes are the address, summary, and computed attributes. The address attributes

describe the flow’s address at transport, network and adjacent layers, whereas the summary attributes include information about time or first and last packets in a flow, and total byte and packet counts. Computed attributes are higher-level derived measurements such as a flow’s index in the flow table. They mainly provide a way of distinguishing flows observed at different times by the meter31.

31 _{The extended RTFM architecture [HaSB99] defines additional distribution-valued attributes like}

packet sizes and intra-flow inter-arrival times, which can be executed on-demand by the meters upon reading of each packet header. This extended architecture also specifies attributes to measure quantities defined within the Integrates Services (IntServ) architecture and in the IPPM WG (see §2.2.2).

This usage data is maintained and held by the meter in an array of flow data records (flow table), and it is collected by the meter reader, at regular reporting intervals. Individual attribute values, complete flows, or the entire flow table can be transferred using different protocols (e.g. FTP), however within RTFM a meter MIB has been defined which can be used to transfer flow data between meters and meter readers through SNMP [Brow99b].

The manager is responsible for configuring and controlling both meters and meter readers, by setting parameters such as flow specifications and sampling behaviour to the former, and by specifying flow collection and attribute values parameters to the latter. The details of analysis applications which will eventually process the usage data collected by the meter readers have not been described within the RTFM architecture.

The granularity of the flow measurements is a very important factor influencing the performance trade-off between the level of measurement detail and the overhead associated with performing and storing flow state in the meters. In RTFM, granularity is mainly controlled through the address attributes and the lifetime of a flow. Each flow has an associated inactivity timeout variable specifying the minimum time after which, if no packets of the flow have been received, the flow is considered idle, and the meter can recover its record. The inactivity timeout is set by a manager to the meter and, under normal operation, the meter can reclaim flow records if this timeout has expired and the record has been collected by a meter reader.

RTFM is a generalised, asynchronous and distributed system, which can measure network flows equally well for a variety of networking stacks and protocols, such as IPv4, IPv6, AppleTalk, and Novell IPX. Its architecture document specifies in detail the structure of the three main conceptual entities, their structures and algorithms, and their inter-operational functions and communication [BrMR99]. The RTFM working group concluded in October 2000.

• NeTraMet

NeTraMet [Brow01, Brow97] is the first open source software implementation of the RTFM system that builds up packet and byte counts for traffic flows, which are defined by their endpoint protocol or transport addresses, or a combination of these. The toolkit consists of

RTFM meters, compilers that parse the rulsets32 _{specified by the managers to be executed by} the meters, and combined meter-readers/managers. NeTraMet can measure flows over a variety of network topologies and different configurations, as shown in Figure 2-13. A single meter can run on a Unix® or Linux host observing all traffic passing through a site via a hub in the case of an Ethernet segment, or via inbound/outbound optical splitters in case of a point-to-point fibre. Under a different operational configuration, it is possible for multiple meters to observe flows at physically different points throughout a (ISP) network and download data to a single remote manager/meter-reader. NeMaC is the combined RTFM manager and meter reader that downloads rulesets to NeTraMet meters, configuring which flows to be metered and in what granularity levels. NeMaC also specifies the flow collection intervals and which attributes of each flow should be read; it then reads flow data from the meter and writes it to flow data files. Redundant data collection can also be provided by having multiple instances of NeMaC all downloading flow data from all the meters.

Figure 2-13: Different NeTraMet Configurations

Additionally, a version of the RTFM meter has been implemented to retrieve Netflow (see section 2.3.2.2) data from Cisco® routers. NetFlowMet, instead of observing packet headers directly, it operates as a parser for data collected by Netflow itself, and it can aggregate Netflow data from many routers, to be later processed by NeMaC. Overall, NeTraMet is reported to have been used for production traffic measurements by ISP, enterprise, and research networks, on links at speeds from 10/100 Mb/s to OC3 and above [Brow01]. A

32 _{RTFM rulsets are configuration files written in the Simple Rulset Language (SRL), which was}

specified within the RTFM working group [Brow99c]. Rulsets are used by the managers to control and configure the meters.

variant version of the software also exists that uses the CoralReef architecture (see section 2.3.3.4) to access packet headers collected by dedicated ATM measurement cards [DAG]. If hardware vendors choose to implement the RTFM meter MIB in switches and routers, then the RTFM system can avoid deploying software-based meters. Instead, they would then become an integral part of the Internet switching infrastructure, substantially improving the performance requirements, overhead, and widespread use of RTFM/NeTraMet.

The NeTraMet implementation has been further used by researchers to characterise Internet flows based on their lifetime as well as on their byte volumes. These studies decomposed measured traffic into three granularity categories: streams were defined to be individual IP sessions between ports on pairs of hosts, flows are sets of packets travelling between two net- blocks (hosts or networks) in either direction, and torrents describe the overall traffic aggregate on a given link [BrMu01]. It was suggested that streams can be classified not only by their size33_{, but also by their lifetime into dragonflies lasting up to two seconds, short} lasting up to fifteen minutes, and tortoises lasting more than fifteen minutes. Measurements over specific Internet paths revealed that although about 1.5% of streams were long-running, up to 50% of all bytes were accounted to these tortoises [BrCl02].

Recent studies also focused on defining dynamic flow timeout algorithms, arguing that a fixed timeout identical for all flows which had been used in the past, was not optimal to satisfy the high variability between different flow durations. NeTraMet uses packet inter-arrival times of the streams comprising a flow to compute its inactivity time [BrMu01], whereas a different study suggested an adaptive flow timeout strategy based on the flow’s throughput during its initial period, in order to preserve long-lived flows and at the same time minimise flow- holding times [RyCB01].