In the previous section, we described the basic idea behind a traffic flow, which is to aggregate traffic that matches certain criteria. What we have not spoken about yet is how those criteria can be defined.
The most important advantage of our very general definition is that the communicating entities are not yet specified any further. Until now, we only assumed that they are two machines on the network that communicate with each other. However, the entities do not have to correlate with machines (i.e. network addresses) but they can as well be whole subnets of machines, classes of applications or autonomous systems . In fact, anything that can be used to distinguish data packets is a potential criteria. In the following sections we will further specify which criteria can be used for the so called ``flow specification''.
A first proposal for a flow specification was given by Partridge in RFC1363 . This proposal is however mainly motivated by the ideas of resource reservation functionality. Therefore, Partridges flow specification is focused on Quality of Service (QoS) parameters which shall be used for the reservation of bandwidth for certain kinds of multimedia traffic. The flow specification he proposes is to be used by the network for admission control and resource allocation purposes.
For network measurement and analysis -- our main interest -- we need a different approach. Our aim is to aggregate as much information about the high amount of data that is transferred as possible and at the same time to use as less memory for this aggregation as needed. Since we have usually do not know in advance what we are searching for and what we want to measure, we need a flexible way to define what kinds of traffic we want to aggregate.