If you don't like that one, I suggest RFC 2460, from which the following is extracted:

   A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. The nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. The details of such control protocols or options are beyond the scope of this document.

   There may be multiple active flows from a source to a destination, as well as traffic that is not associated with any flow. A flow is   uniquely identified by the combination of a source address and a    non-zero flow label. Packets that do not belong to a flow carry a    flow label of zero.

   A flow label is assigned to a flow by the flow's source node. New flow labels must be chosen (pseudo-)randomly and uniformly from the   range 1 to FFFFF hex. The purpose of the random allocation is to    make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the   flow.

   All packets belonging to the same flow must be sent with the same
source address, destination address, and flow label. If any of those
packets includes a Hop-by-Hop Options header, then they all must be
originated with the same Hop-by-Hop Options header contents (excluding the Next Header field of the Hop-by-Hop Options header).   If any of those packets includes a Routing header, then they all must
be originated with the same contents in all extension headers up to
and including the Routing header (excluding the Next Header field in
the Routing header). The routers or destinations are permitted, but
not required, to verify that these conditions are satisfied. If a
violation is detected, it should be reported to the source by an ICMP
Parameter Problem message, Code 0, pointing to the high-order octet
of the Flow Label field (i.e., offset 1 within the IPv6 packet).

   The maximum lifetime of any flow-handling state established along a
flow's path must be specified as part of the description of the
state-establishment mechanism, e.g., the resource reservation
protocol or the flow-setup hop-by-hop option. A source must not re- use a flow label for a new flow within the maximum lifetime of any   flow-handling state that might have been established for the prior
use of that flow label.

   When a node stops and restarts (e.g., as a result of a "crash"), it
must be careful not to use a flow label that it might have used for
an earlier flow whose lifetime may not have expired yet. This may be
accomplished by recording flow label usage on stable storage so that
it can be remembered across crashes, or by refraining from using any
flow labels until the maximum lifetime of any possible previously
established flows has expired. If the minimum time for rebooting the
node is known, that time can be deducted from the necessary waiting
period before starting to allocate flow labels.

This, of course, refers to IPv6 and not IPv4.