Re: [IPFIX] Export of long lived flow information
Paul Aitken <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Andrew,
> I was thinking that a mechanism that allowed a non-permanent flow to be exported multiple time would be useful. For example, security applications generally want to know about a new flow ASAP, so they can act on the information, but a short active timeout values lead to using more export bandwidth. I was thinking we could do something like export a report of the flow after the first packet, and then export the final version of the flow once the normal timeouts had decided it was over.
I have in the past discussed the idea of exporting a "new flow alert"
using zero-valued counters in order to make the collector aware that
we've started monitoring it - so I'm claiming prior art on that.
> I had in mind something like using a delta count, followed by a total count. Reading the below definition of Total counts though, I'm not sure that will work, but I think it depends on how we interpret the definition of "Flow". If two records have matching key fields but different starting timestamps, are they the same Flow?
5101 defines:
A Flow is defined as a set of IP packets passing an Observation
Point in the network during a certain time interval.
- so it's all about the timestamps :-)
> I would argue that a single Flow can't have two flowStartTimes, so maybe not.
However, two flows with different flowStartTimes can be merged into one
flow.
> This would mean that we shouldn't reset the flowStartTimes between sending reports for the same permanent Flow.
Definitely. If it's a permanent flow and you're exporting totalCount
fields - which are measured "since the Metering Process
(re-)initialization for this Observation Point" - then the flowStartTime
must surely be the time the first ever packet was observed.
P.
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix