Subject: Fwd: Standard Flow Export - definition of 'flows'

From: Michael MacFaden <[email-masked]>
Date: Mon, 26 Mar 2001 09:28:31 -0800

>At 03:58 PM 3/26/2001 +1200,  Nevil Brownlee <[email-masked]>
>[snip]
>>A. Standard Flow Export
>>
>>The requirement here is for a standard definition
>>of traffic flows, together with effective transport
>>mechanisms allowing both push and pull of large
>>amounts of flow data.  Current systems for this
>>(in the public domain) include NetFlow (Cisco),
>>LFAP (Riverstone) and RTFM.  A working group to
>>develop such a standard would fit well in the
>>Ops & Management Area.
>>
>>Mike McFaden (Riverstone) and Chris Elliott (Cisco)
>>agreed to start moves towards forming a Working Group,
>>by initiating discussion on the RTFM mailing list,
>>To begin with, we'd like to gather opinions as to what
>>we really mean when we speak of 'flows.'
>
>Great, so let's begin!
>
>Rekhter and Davies use the following in
>"MPLS Technologies and Applications" on
>
>page 155:
>    individual application flows - microflows
>
>page 196
>    A traffic trunk is defined as a collection of individual TCP,
>    or UDP, flows, known as "microflows"  that share two
>    common properties.   The first one is that all microflows
>    are forwarded along the same common path.
>    The second is that they all share the same Class of Service.
>
>But as Rekhter and Davies point out, scaling anything that deals
>with microflows is difficult and thus is quickly relegated further
>towards the edge of a network as traffic volume increases.
>
>Regards,
>Mike MacFaden
>www.riverstonenet.com

---

From: Dave Plonka <[email-masked]>
Date: Mon, 26 Mar 2001 14:48:47 -0600

> >>we really mean when we speak of 'flows.'

In my mind, the IP flow definition would go something more along these
lines:

   An IP flow is a unidirectional series of IP packets of a given
   protocol, traveling between a source and destination, within a
   certain period of time.

   The source and destination are defined, at least, by IP address,
   forming a "host pair".

   For IP protocols which further qualify the source and destination
   endpoints with a /port/ number, those port numbers become part of
   the source and destination, forming a "host and port quadruple"
   (source-address, source-port, destination-address,
   destination-port).

Some of that is glommed from my paper here:

    http://net.doit.wisc.edu/~plonka/lisa/FlowScan/#ToC4
    http://net.doit.wisc.edu/~plonka/lisa/FlowScan/out.ps.gz

where I referenced Claffy, K. C. and Braun, Hans-Werner and Polyzos,
George C.:

   http://www.caida.org/outreach/papers/itf.html

> >    are forwarded along the same common path.

I follow-up with a seperate post regarding the consequences of
including the "forwarded along the same common path" statement in the
flow definition.

> >towards the edge of a network as traffic volume increases.

I'll post another follow-up focusing on flow duration.  This is
directly related to scaling as it defines how much state information a
device must keep regarding flows.

Dave

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

---

From: Dave Plonka <[email-masked]>
Date: Mon, 26 Mar 2001 15:04:07 -0600

> >    The second is that they all share the same Class of Service.

If "forwarded along the same common path" were part of our flow
definition I'm wondering if that means an IP flow would be defined by
input and output ifIndex as NetFlow or LFAP flows are currently with a
single input and output ifIndex?

If so, this is somewhat problematic for IP mulicast traffic since the
set of egress interfaces can change on a multicast-aware IP router or
switch.  It would be a shame to have to terminate/export multicast
flows whenever the set of egress interfaces changed because of a new
host joining an existing multicast group.

I think I'm OK with leaving the ingress interface (ifIndex) as part of
the flow def'n. but I'm wondering if we can create a new method by
which output ifIndexes can be added and removed without terminating the
flow.  (A flow update... this means that each flow would need to have a
unique identifier/handle/label by which the flow could be referred in
an update.)

I just wanted to mention this issue now (so as not to forget it)...
perhaps it can be revisited when export PDUs are discussed.

However, I do think it's important to be sure that we consider the
consequences if the flow definition causing us to have to terminate an
export multicast flows every time a multicast group join or leave
occurs.

That said, "forwarded along the same common path" (as defined by an
"ifIndex pair") is a clause to use for unicast IP traffic.

Dave

---

From: Paul Calato <[email-masked]>
Date: Mon, 26 Mar 2001 20:41:25 -0500

I'll muddy the waters a little further. A flow is a user
defined key. One customer may need to have data collected
based on source and destination IP, while another needs 
it based on source and destination AS and still another
needs it based solely on ingress port.

Thus you either have to have an all encompasing key so that
the aggregates can be calculated with post processing or
you need a way to allow the key to be set.

Paul

---

From: Remco Poortinga <[email-masked]>
Date: Tue, 27 Mar 2001 09:25:38 +0200

Hello all,

Dave Plonka wrote:
[snip] 
>    protocol, 

[insert]
and Class of Service
(and maybe more/others if we look at the IPv6 header?)

>traveling between a source and destination, within a
>    certain period of time.

Cheers,

Remco

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 27 Mar 2001 15:16:43 +0200

> "ifIndex pair") is a clause to use for unicast IP traffic.

I don't think the term "path" is appropriate here. You did well by
defining it given by an "ifIndex pair", but the general understanding
of the term is different and more general, particularly in the 
definition of an MPLS traffic trunk cited above.

In an MPLS domain, each packet with the same source and destination 
address takes exactly the same path, not just in terms of interfaces 
of a single device, but in terms of all routers in the domain. 
This does not hold in general in IP networks.

If we adopt the term path, but define it differently (as you suggested),
we will confuse a lot of people.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd., C&C Research Laboratories   Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Marcelo Pias <[email-masked]>
Date: Tue, 27 Mar 2001 16:11:52 +0100 (BST)

Hello,

>    protocol, traveling between a source and destination, within a

I think the above definition fits quite well in a general sense. Things
that I believe should be considered are: 

	(a) granularity of flow (fine or bulk). Do we need to have this
distinction in the definition? Or it's just matter of how you
identify a flow?

	(b) a flow definition *without including ways to identify a flow*

	(c) flow identification as any combination of IP address, port
numbers, flow label (ipv6), flowID, ifIndex...

My suggestion would be to not mix "flow definition" with its
identification since we can use any combination of identification which would lead to a 
more generic definition. 

Cheers. Marcelo

---

From: Dave Plonka <[email-masked]>
Date: Tue, 27 Mar 2001 09:49:40 -0600

> you need a way to allow the key to be set.

OK, then I see a couple sorts of directions we could go with this flow
definition:

1) A simple definition, such as:

      A "standard" IP flow is a seqeunce of IP packets [...].

   This sort of defintion lets the implementor know what information
   they must maintain in the "flow" and what may be discarded.  (For
   instance, mid-flow packet arrival times and IP payload can be
   discarded.)  This definition is a sort of recipe for converting a
   trace consisting of IP packet headers into flow records.

   Note that this sort definition does not preclude an implementor from
   providing aggregate counters that tally totals across like flows.

2) A complex definition, such as:

      A "standard" IP flow as a nebulous thing, defined by set of
      user-defined "keys" [...].

   This sounds like the sort that Paul suggests, and I think is what
   NeTraMet allows.

   This definition ties the concept of arbitrary aggregation (for
   counters) into the flow definition.

   Is this necessary?  Perhaps we wouldn't really lose anything by
   writing the simpler definition (1) because aggregation can still be
   subsequently defined and implemented on either the router/switch or
   in the collector/post-processor.

With this 2nd type of definition, the term "flow" remains nebulous (as
it is today).  Personally, I'd like to be able to talk with someone
about "RFCn standard" IP flows, and have a pretty good idea what they
are talking about without them having to enumerate the
application-specific key values.  I'd rather those be a function of the
flow's IP protocol.

If you agree, then perhaps we can first define the standard IP flow -
the atomic data object.  Then, using terminology such as Paul
suggested, we can define the methods of aggregation which can be
applied to those primitive data objects.

Dave

---

From: Dave Plonka <[email-masked]>
Date: Tue, 27 Mar 2001 10:21:27 -0600

> (and maybe more/others if we look at the IPv6 header?)

Rather than attempting to enumerate all the "keys" which could be used
to define an IP flow, I've been wondering if these "keys" should be
defined to be whatever set of IP header fields which the router is
capable of using to make filtering or forward decisions.

I.e. It may be permissible for a given device, which is capable of only
"traditional" routing based on IP destination and has simple ACLs to
block by address and port, to maintain flow records defined solely by
IP protocol and src/dst addresses.

However, another piece of gear which is capable of doing some sort of
policy routing based upon port numbers should have a standard flow
[export] implementation that must be capable of including the TCP/UDP
port numbers as a key that defines a flow.  Similarly, if a router is
MPLS-capable, then the flow's LSP might be one of the keys that define
a flow.

As such, the work required (on the part of the router) to maintain flow
information, should be somewhat similar to that of the filter-based
forwarding or policy routing features that the router already
implements.  Hopefully, this will keep the flow features from being
prohibitive to implement because of the performance deficit.

For example, LFAP currently doesn't report TCP flags values in TCP
flows because its low-level flow "engine" can't observe these flags
from arbitrary packets amidst a flow.  (Since Riverstone routers don't
have any options to forward based upon TCP flags values, this makes
some sense.)

Also, a vendor, who adds some fancy policy routing or QoS features,
would be required to correspondingly improve the flow features (to make
them aware of the new "key" values) to maintain compliance with the
"standard IP flow" spec.

Unfortunately, I'm thinking we're getting into murky waters here since
all these new policy-based filtering and forwarding features are not
standards-defined, correct?

Is there some shorthand way that we can say that the flows should be as
"smart" as the router?

Dave

---

From: "Carter Bullard" <[email-masked]>
Date: Tue, 27 Mar 2001 12:28:05 -0500

Gentle people,
I would recommend adopting the terminology that IPPM is using.
Flows can easily be defined using the "Type-P" notation.  Its
extensible and it provides the direct hook back to the IPPM
framework, which could/should be used as a guide.

Interface numbers and prev/next hop AS numbers are not
derivable from packet contents, and as such, may not be
appropriate for identifying packet flows in a generic sense.
Its great that they can be provided in flow reports, but it
may not be appropriate to make them a part of the standard
flow key definition.

As an example, there are no AS numbers in an OSPF or RIP
network, but there are plenty of flows.  There are area
numbers in OSPF, but nothing in RIP.  In load balanced 
multi-trunk environments, there can be many interfaces that
are used to support a single VoIP call, but the design
should allow for the single flow to reported once.  And
finally, a flow meter implemented on a single ingress
interface may not know what the ultimate egress interface
will be for a packet that it is classifying and reporting
on, so the output interface can't be a part of this particular
flow model.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Juergen Quittek
> Sent: Tuesday, March 27, 2001 8:17 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: IP flow def'n: "forwarded along the same common path"?
> multicast consequences?
> 
> 
> Dave Plonka wrote:
> >

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 28 Mar 2001 10:39:07 +0200

> Carter Bullard wrote:

Well, we are already back to the requirements. 

Your requirement here is having a single VoIP data stream 
being reported as a single flow. Another one could be having 
packets accounted separately if they leave a router at different 
interfaces.

At first sight, both requirements seem reasonable to me,
but maybe they contradict each other as you claim.

So, lets first find out what our requirements are.
Then it  should be much easier to agree on a flow model.
If the Type-P notation matches our requirements, it could 
be a very good idea to use it.

> on, so the output interface can't be a part of this particular

Here we have another requirement. While your first one was
a kind of usage requirement, this looks like an implementation 
requirement.

    Juergen

---

From: "Carter Bullard" <[email-masked]>
Date: Wed, 28 Mar 2001 09:27:49 -0500

Gentle people,
   Argus is IP flow monitor that has a push data model
and a TLV data format for its flow reports.  It is open
source software, and has been around for a while.  I can
offer this as an example implementation for discussion.

   http://qosient.com/argus

If it would help the effort, I can give a discussion of
Argus's design strategy at the London IETF.

Carter

Carter Bullard
QoSient, LLC

[email-masked]
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com