One document matched: draft-trammell-ipfix-a9n-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-trammell-ipfix-a9n-03.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="IPFIX Aggregation">
Exporting Aggregated Flow Data using the IP Flow Information Export (IPFIX) Protocol
</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<phone>+41 44 632 70 13</phone>
<email>trammell@tik.ee.ethz.ch</email>
</address>
</author>
<author initials="E." surname="Boschi" fullname="Elisa Boschi">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<email>boschie@tik.ee.ethz.ch</email>
</address>
</author>
<author initials="A." surname="Wagner" fullname="Arno Wagner">
<organization abbrev="Consecom AG">
Consecom AG
</organization>
<address>
<postal>
<street>Bleicherweg 64a</street>
<city>8002 Zurich</city>
<country>Switzerland</country>
</postal>
<email>arno@wagner.name</email>
</address>
</author>
<author initials="B." surname="Claise" fullname="Benoit Claise">
<organization abbrev="Cisco Systems, Inc.">
Cisco Systems, Inc.
</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>1831 Diagem</city>
<country>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
</address>
</author> <date month="June" day="29" year="2011"></date>
<area>Operations</area>
<workgroup>IPFIX Working Group</workgroup>
<abstract>
<t>This document describes the export of aggregated Flow information using
IPFIX. An Aggregated Flow is essentially an IPFIX Flow representing
packets from multiple original Flows sharing some set of common
properties. The document describes Aggregated Flow export within the
framework of IPFIX Mediators and defines an interoperable,
implementation-independent method for Aggregated Flow export.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The aggregation of packet data into Flows serves a variety of
different purposes, as noted in the <xref
target="RFC3917">requirements</xref> and <xref
target="RFC5472">applicability statement</xref> for the IP Flow
Information Export (IPFIX) <xref target="RFC5101">protocol</xref>.
Aggregation beyond the flow level, into records representing multiple
Flows, is a common analysis and data reduction technique as well, with
applicability to large-scale network data analysis, archiving, and
inter-organization exchange. This applicability in large-scale
situations, in particular, led to the inclusion of aggregation as part
of the <xref target="RFC5982">IPFIX Mediators Problem
Statement</xref>, and the definition of an Intermediate Aggregation
Process in the <xref
target="I-D.ietf-ipfix-mediators-framework">Mediator
framework</xref>.</t>
<!-- <t>The Mediator framework offers an initial treatment of the topic of
aggregation in defining a placeholder for the Intermediate Aggregation
Process. This document expands on the definitions presented there,
specifying an Intermediate Aggregation Process which can operate
within an IPFIX Mediator or together with an IPFIX Metering
Process.</t> -->
<t>Aggregation is part of a wide variety of applications, including
traffic matrix calculation, generation of time series data for
visualizations or anomaly detection, or measurement data reduction.
Depending on the keys used for aggregation, it may additionally have
an anonymising affect on the data: for example, aggregation operations
which eliminate IP addresses make it impossible to later identify
nodes using those addresses.</t>
<!-- <t> Aggregation can take place at one of any number of locations
within a measurement infrastructure. Aggregation may be applied to
original Flow information collected at an IPFIX Mediator from multiple
original Exporters at multiple geographically and topologically
separate Observation Points for analytic and data reduction purposes.
Exporters may directly export Aggregated Flow information, as well, by
performing aggregation after metering but before export.</t>-->
<t>Aggregation as defined and described in this document covers the
applications defined in <xref target="RFC5982"/>, including 5.1
"Adjusting Flow Granularity", 5.4 "Time Composition", and 5.5 "Spatial
Composition". However, this document specifies a more flexible
architecture for an Intermediate Aggregation Process in <xref
target="sec-iap-arch"/>, which supports a superset of these
applications.</t>
<t>An Intermediate Aggregation Process may be applied to data
collected from multiple Observation Points, as aggregation is natural
to apply for data reduction when concentrating measurement data. This
document specifically does not address the protocol issues that arise
when combining IPFIX data from multiple Observation Points and
exporting from a single Mediator, as these issues are general to IPFIX
Mediation; they are therefore treated in detail in the <xref
target="I-D.claise-ipfix-mediation-protocol">Mediator Protocol</xref>
document.</t>
<t>Since Aggregated Flows as defined in the following section are
essentially Flows, the IPFIX protocol <xref target="RFC5101"/> can be
used to export, and the IPFIX File Format <xref target="RFC5655"/> can
be used to store, aggregated data "as-is"; there are no changes
necessary to the protocol. This document provides a common basis for
the application of IPFIX to the handling of aggregated data, through a
detailed terminology, Intermediate Aggregation Process architecture,
and methods for original Flow counting and counter distribution across
intervals.</t>
<!-- <section title="Rationale and Scope">
<t>From the definition of presented below in <xref
target="sec-terminology"/>, an Aggregated Flow is a simply a Flow
as in <xref target="RFC5101"/>. Practically speaking, Aggregated
Flows are generally derived from original Flows, as opposed to a
raw packet stream, where the original Flows may themselves be
Aggregated Flows, in the case of multi-stage aggregation. Key to
this definition of Aggregated Flow is how timing affects the
process of aggregation, as for the most part flow aggregation
takes place within some set of time intervals, either regular
(e.g. for five-minute time series aggregation), or derived from
the flows themselves. Aggregation operations concerning keys,
which are often called "spatial aggregation" in the literature
(e.g, the <xref target="RFC5835">Framework for Metric
Composition</xref>), will necessarily impact and be impacted by
these time intervals; aggregation operations concerning these time
intervals are often called "temporal aggregation" in the
literature. These definitions of aggregation attempt to treat
temporal and spatial aggregation separately. This document
recognizes that this is not possible in the case of IPFIX
Aggregated Flows (aside from simple time composition as defined in
section 5.4 of <xref target="RFC5982"/>, which we treat as a
special case); due to the interdependencies between flows and
their time intervals, this document defines these operations as
interdependent.</t>
<t>Though we specify an Intermediate Aggregation Process in terms
of a sequence of operations in <xref target="sec-model"/> due to
this interdependency, this should be seen as a descriptive model,
as with the <xref target="RFC5470">IPFIX Architecture</xref>. This
model is not meant to specify a design for such an Intermediate
Aggregation Process. Also specifically out of scope for this
effort are any definition of a language for defining aggregation
operations, or the configuration parameters of Aggregation
Processes, as these are necessarily implementation dependent.</t>
</section> -->
<!--
<section title="Related IPFIX Documents"/>
<t>[EDITOR'S NOTE: TODO roadmap goes here]</t>
</section>
-->
</section>
<section title="Terminology" anchor="sec-terminology">
<t>Terms used in this document that are defined in the Terminology
section of the <xref target="RFC5101">IPFIX Protocol</xref> document
are to be interpreted as defined there.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>In addition, this document defines the following terms</t>:
<list style="hanging">
<t hangText="Aggregated Flow: ">A Flow, as defined by <xref
target="RFC5101"/>, derived from a set of zero or more original
Flows within a defined Aggregation Interval. The two primary
differences between a Flow and an Aggregated Flow are (1) that the
time interval of a Flow is generally derived from information
about the timing of the packets comprising the Flow, while the
time interval of an Aggregated Flow are generally externally
imposed; and (2) that an Aggregated Flow may represent zero
packets (i.e., an assertion that no packets were seen for a given
Flow Key in a given time interval). Note that an Aggregated Flow
is defined within the context of an Intermediate Aggregation
Process only. once an Aggregated Flow is exported, it is
essentially a Flow as in <xref target="RFC5101"/> and can be
treated as such.</t>
<t hangText="Intermediate Aggregation Function: ">A mapping from a
set of zero or more original Flows into a set of Aggregated Flows
across one or more Aggregation Intervals. This function is hosted
by an Intermediate Aggregation Process, defined below.</t>
<t hangText="Intermediate Aggregation Process: ">an Intermediate
Process as in <xref target="I-D.ietf-ipfix-mediators-framework"/>
that aggregates records based upon a set of Flow Keys or functions
applied to fields from the record; this is itself defined in <xref
target="I-D.ietf-ipfix-mediators-framework"/>.</t>
<t hangText="Aggregation Interval: ">A time interval imposed upon
an Aggregated Flow. Aggregation Functions may use a regular
Aggregation Interval (e.g. "every five minutes", "every calendar
month"), though regularity is not necessary. Aggregation intervals
may also be derived from the time intervals of the original Flows
being aggregated.</t>
<!-- <t hangText="Interval Distribution: ">A temporal aggregation
operation which imposes a new time interval on an original Flow,
an Aggregated Flow produced by some other operation, or a set
thereof. Interval Distribution is a many-to-many operation: it may
result in the values from an original Flow appearing in multiple
Aggregated Flows as well as in multiple original Flows
contributing to each imposed time interval.</t>
<t hangText="Interval Combination: ">A temporal aggregation
operation which combines temporally adjacent original Flows with
matching Flow Keys, expanding the interval of the combined Flow to
cover the entire interval covered by the set of original
Flows.</t>
<t hangText="Key Aggregation: ">A spatial aggregation operation
that generates new Aggregated Flows from original Flows by
modifying the Flow Key. Key Aggregation is usually applied in
combination with an Interval Distribution operation.</t>
-->
<t hangText="partially aggregated Flow: ">A Flow during processing
within an Intermediate Aggregation Process; refers to an
intermediate data structure during aggregation within the
Intermediate Aggregation Process architecture detailed in <xref
target="sec-iap-arch"/>.</t>
<t hangText="original Flow: ">A Flow given as input to an
Aggregation Function in order to generate Aggregated Flows.</t>
<t hangText="contributing Flow: ">An original Flow that is
partially or completely represented within an Aggregated Flow.
Each aggregated Flow is made up of zero or more contributing
Flows, and an original Flow may contribute to zero or more
Aggregated Flows.</t>
</list>
</section>
<section title="Use Cases for IPFIX Aggregation" anchor="sec-usecase">
<t>Aggregation, as a common data analysis method, has many
applications. When used with a regular Aggregation Interval, it
generates time series data from a collection of Flows with discrete
intervals. Time series data is itself useful for a wide variety of
analysis tasks, such as generating input for network anomaly
detection systems, or driving visualizations of volume per time for
traffic with specific characteristics. Traffic matrix calculation from
flow data is inherently an aggregation action, by aggregating the Flow
Key down to input or output interface, address prefix, or autonomous
system.</t>
<t>Irregular or data-dependent Aggregation Intervals and key
aggregation operations can also be used to provide adaptive
aggregation of network flow data. Here, full Flow Records can be kept
for Flows of interest, while Flows deemed "less interesting" to a
given application can be aggregated. For example, in an IPFIX Mediator
equipped with traffic classification capabilities for security
purposes, potentially malicious Flows could be exported directly,
while known-good or probably-good Flows (e.g. normal web browsing)
could be exported simply as time series volumes per web server.</t>
<t>Note that an Intermediate Aggregation Function which removes
potentially sensitive information as identified in <xref
target="I-D.ietf-ipfix-anon"/> may tend to have an anonymising effect
on the Aggregated Flows, as well; however, any application of
aggregation as part of a data protection scheme should ensure that all
the issues raised in Section 4 of <xref target="I-D.ietf-ipfix-anon"/>
are addressed.</t>
</section>
<section title="Architecture for Flow Aggregation">
<t>This section specifies how an Intermediate Aggregation Process fits into the IPFIX Architecture, and the architecture of the Intermediate Aggregation Process itself.</t>
<section title="Aggregation within the IPFIX Architecture" anchor="sec-arch">
<t>An Intermediate Aggregation Process may be deployed at three places within the IPFIX Architecture. While aggregation applications are most commonly deployed within a Mediator which collects original Flows from an original Exporter and exports Aggregated Flows, aggregation can also occur before initial export, or after final collection, as shown in <xref target="loc-fig"/>.</t>
<figure title="Potential Aggregation Locations" anchor="loc-fig">
<artwork><![CDATA[
+==========================================+
| Exporting Process |
+==========================================+
| |
| (Aggregated Flow Export) |
V |
+=============================+ |
| Mediator | |
+=============================+ |
| |
| (Aggregating Mediator) |
V V
+==========================================+
| Collecting Process |
+==========================================+
|
| (Aggregation for Storage)
V
+--------------------+
| IPFIX File Storage |
+--------------------+
]]></artwork>
</figure>
<t>The Mediator use case is further shown in Figures A and B in <xref
target="I-D.ietf-ipfix-mediators-framework"/>.</t>
<t>Aggregation can be applied for either intermediate or final
analytic purposes. In certain circumstances, it may make sense to
export Aggregated Flows directly from an original Exporting Process,
for example, if the Exporting Process is applied to drive a
time-series visualization, or when flow data export bandwidth is
restricted and flow or packet sampling is not an option. Note that
this case, where the Aggregation Process is essentially integrated
into the Metering Process, is essentially covered by the <xref
target="RFC5470">IPFIX architecture</xref>: the Flow Keys used are
simply a subset of those that would normally be used. A Metering
Process in this arrangement MAY choose to simulate the generation of
larger Flows in order to generate original Flow counts, if the
application calls for compatibility with an Aggregation Process
deployed in a separate location.</t>
<t>In the specific case that an Aggregation Process is employed for
data reduction for storage purposes, it can take original Flows from a
Collecting Process or File Reader and pass Aggregated Flows to a File
Writer for storage.</t>
<t>Deployment of an Intermediate Aggregation Process within a <xref
target="RFC5982">Mediator</xref> is a much more flexible arrangement.
Here, the Mediator consumes original Flows and produces aggregated
Flows; this arrangement is suited to any of the use cases detailed in
<xref target="sec-usecase"/>. In a mediator, aggregation can be
applied as well to aggregating original Flows from multiple sources
into a single stream of aggregated Flows; the architectural specifics
of this arrangement are not addressed in this document, which is
concerned only with the aggregation operation itself; see <xref
target="I-D.claise-ipfix-mediation-protocol"/> for details.</t>
<t>The data paths into and out of an Intermediate Aggregation Process
are showin in <xref target="iap-dataflows"/>.</t>
<figure title="Data paths through the aggregation process" anchor="iap-dataflows">
<artwork><![CDATA[
packets --+ +- IPFIX Messages -+
| | |
V V V
+==================+ +====================+ +=============+
| Metering Process | | Collecting Process | | File Reader |
| | +====================+ +=============+
| | | original Flows |
| | V V
+ - - - - - - - - -+======================================+
| Intermediate Aggregation Process (IAP) |
+=========================================================+
| Aggregated Aggregated |
| Flows Flows |
V V
+===================+ +=============+
| Exporting Process | | File Writer |
+===================+ +=============+
| |
+------------> IPFIX Messages <----------+
]]></artwork>
</figure>
</section>
<section title="Intermediate Aggregation Process Architecture" anchor="sec-iap-arch">
<t>Within this document, an Intermediate Aggregation Process can be
seen as hosting an Intermediate Aggregation Function composed of four
types of operations on the intermediate results of aggregation, which
are called partially aggregated Flows in this document, as illustrated
in <xref target="iap-arch-diagram"/>.</t>
<figure title="Conceptual model of aggregation operations" anchor="iap-arch-diagram"><artwork><![CDATA[
original Flows
|
V
+-----------------------+
| interval distribution |
+-->| (temporal) |<--+
| +-----------------------+ |
| | | | |
|(*) |(*) |(*) |(*) |(*)
| | | | |
| V | V |
+-------------------+ | +--------------------+
| key aggregation | | | value aggregation |
| (spatial) | | | (spatial) |
+-------------------+ | +--------------------+
^ | | | ^
| |(*) | |(*) |
+-------|-------|-------|-------+
V V V
+-------------------------+
| aggregate combination |
+-------------------------+
|
V
Aggregated Flows
(*) partially aggregated Flows
]]></artwork></figure>
<list style="hanging">
<t hangText="Interval distribution"> is a temporal aggregation
operation which imposes an Aggregation Interval on the partially
aggregated Flow. This Aggregation Interval may be regular,
irregular, or derived from the timing of the original Flows
themselves. Interval distribution is discussed in detail in <xref
target="sec-iap-interval"/>.</t>
<t hangText="Key aggregation "> is a spatial aggregation operation
which results in the addition, modification, or deletion of Flow
Key fields in the partially aggregated Flows. New Flow Key fields
may be derived from existing Flow Key fields (e.g., looking up an
AS number for an IP address), or "promoted" from non-Key fields
(e.g., when aggregating Flows by packet count per Flow). Key
aggregation can also add new non-Key fields derived from Key
Fields that are deleted during key aggregation; mainly counters of
unique reduced keys. Key aggregation is discussed in detail in
<xref target="sec-iap-key"/>.</t>
<t hangText="Value aggregation "> is a spatial aggregation
operation which results in the addition, modification, or deletion
of non-Key fields in the partially aggregated Flows. These non-Key
fields may be "demoted" from existing Key fields, or derived from
existing Key or non-Key fields. Value aggregation is discussed in
detail in <xref target="sec-iap-value"/>.</t>
<t hangText="Aggregate combination "> combines multiple partially
aggregated Flows having undergone interval distribution, key
aggregation, and value aggregation which share Flow Keys and
Aggregation Intervals into a single aggregated Flow per Flow Key
and Aggregation Interval. Aggregate combination is discussed in
detail in <xref target="sec-iap-combo"/>.</t>
</list>
<t>The first three of these operations may be carried out any number
of times in any order, either on original Flows or on the results of
one of the Operations (called partially aggregated Flows), with one
caveat. Since Flows carry their own interval data, any spatial
aggregation operation implies a temporal aggregation operation, so at
least one interval distribution step, even if implicit, is required by
this architecture. This is shown as the first step for the sake of
simplicity in the diagram above. Once all aggregation operations are
complete, aggregate combination ensures that for a given Aggregation
Interval, Flow Key, and Observation Domain, only one Flow is produced
by the Intermediate Aggregation Process.</t>
</section>
</section>
<section title="IP Flow Aggregation Operations">
<t>As stated in <xref target="sec-terminology"/>, an Aggregated Flow
is simply an IPFIX Flow generated from original Flows by an
Aggregation Function. Here, we detail the operations by which this is
achieved within an Intermediate Aggregation Process.</t>
<section title="Temporal Aggregation through Interval Distribution" anchor="sec-iap-interval">
<t>Interval distribution imposes a time interval on the resulting
Aggregated Flows. The selection of an interval is specific to the
given aggregation application. Intervals may be derived from the
original Flows themselves (e.g., an interval may be selected to
cover the entire interval containing the set of all Flows sharing
a given Key, as in Time Composition describe in <xref
target="sec-timecomp"/>) or externally imposed; in the latter case
the externally imposed interval may be regular (e.g., every five
minutes) or irregular (e.g., to allow for different time
resolutions at different times of day, under different network
conditions, or indeed for different sets of original Flows).</t>
<t>The length of the imposed interval itself has tradeoffs.
Shorter intervals allow higher resolution aggregated data and, in
streaming applications, faster reaction time. Longer intervals
lead to greater data reduction and simplified counter
distribution. Specifically, counter distribution is greatly
simplified by the choice of an interval longer than the duration
of longest original Flow, itself generally determined by the
original Flow's Metering Process active timeout; in this case an
original Flow can contribute to at most two Aggregated Flows, and
the more complex value distribution methods become
inapplicable.</t>
<figure title="Illustration of interval distribution" anchor="intdist-fig">
<artwork><![CDATA[
| | | |
| |<--Flow A-->| | | |
| |<--Flow B-->| | |
| |<-------------Flow C-------------->| |
| | | |
| interval 0 | interval 1 | interval 2 |
]]></artwork>
</figure>
<t>In <xref target="intdist-fig"/>, we illustrate three common
possibilities for interval distribution as applies with regular
intervals to a set of three original Flows. For Flow A, the start
and end times lie within the boundaries of a single interval 0;
therefore, Flow A contributes to only one Aggregated Flow. Flow B,
by contrast, has the same duration but crosses the boundary
between intervals 0 and 1; therefore, it will contribute to two
Aggregated Flows, and its counters must be distributed among these
Flows, though in the two-interval case this can be simplified
somewhat simply by picking one of the two intervals, or
proportionally distributing between them. Only Flows like Flow A
and Flow B will be produced when the interval is chosen to be
longer than the duration of longest original Flow, as above. More
complicated is the case of Flow C, which contributes to more than
two Aggregated Flows, and must have its counters distributed
according to some policy as in <xref target="sec-distro"/>.</t>
<t>[EDITOR'S NOTE: per Lothar: some implementation guidance here would be good. specifically, advise that you need multiple rotating intervals to do this right.]</t>
<section title="Distributing Values Across Intervals" anchor="sec-distro">
<t>In general, counters in Aggregated Flows are treated the same
as in any Flow. Each counter is independently is calculated as
if it were derived from the set of packets in the original Flow.
For the most part, when aggregating original Flows into
Aggregated Flows, this is simply done by summation.</t>
<t>When the Aggregation Interval is guaranteed to be longer than
the longest original Flow, a Flow can cross at most one Interval
boundary, and will therefore contribute to at most two
Aggregated Flows. Most common in this case is to arbitrarily but
consistently choose to account the original Flow's counters
either to the first or the last aggregated Flow to which it
could contribute.</t>
<t>However, this becomes more complicated when the Aggregation
Interval is shorter than the longest original Flow in the source
data. In such cases, each original Flow can incompletely cover
one or more time intervals, and apply to one or more Aggregated
Flows; in this case, the Aggregation Process must distribute the
counters in the original Flows across the multiple Aggregated
Flows. There are several methods for doing this, listed here in
roughly increasing order of complexity and accuracy; most of
these are necessary only in specialized cases.</t>
<list style="hanging">
<t hangText="End Interval: ">The counters for an original
Flow are added to the counters of the appropriate Aggregated
Flow containing the end time of the original Flow.</t>
<t hangText="Start Interval: ">The counters for an original
Flow are added to the counters of the appropriate Aggregated
Flow containing the start time of the original Flow.</t>
<t hangText="Mid Interval: ">The counters for an original
Flow are added to the counters of a single appropriate
Aggregated Flow containing some timestamp between start and
end time of the original Flow.</t>
<t hangText="Simple Uniform Distribution: ">Each counter for
an original Flow is divided by the number of time intervals
the original Flow covers (i.e., of appropriate Aggregated
Flows sharing the same Flow Key), and this number is added
to each corresponding counter in each Aggregated Flow.</t>
<t hangText="Proportional Uniform Distribution: ">Each
counter for an original Flow is divided by the number of
time _units_ the original Flow covers, to derive a mean
count rate. This mean count rate is then multiplied by the
number of time units in the intersection of the duration of
the original Flow and the time interval of each Aggregated
Flow. This is like simple uniform distribution, but accounts
for the fractional portions of a time interval covered by an
original Flow in the first and last time interval.</t>
<t hangText="Simulated Process: ">Each counter of the
original Flow is distributed among the intervals of the
Aggregated Flows according to some function the Aggregation
Process uses based upon properties of Flows presumed to be
like the original Flow. For example, Flow Records
representing bulk transfer might follow a more or less
proportional uniform distribution, while interactive
processes are far more bursty.</t>
<t hangText="Direct: ">The Aggregation Process has access to
the original packet timings from the packets making up the
original Flow, and uses these to distribute or recalculate
the counters.</t>
</list>
<t>A method for exporting the distribution of counters across
multiple Aggregated Flows is detailed in <xref
target="sec-ex-distro"/>. In any case, counters MUST be
distributed across the multiple Aggregated Flows in such a way
that the total count is preserved, within the limits of accuracy
of the implementation (e.g., inaccuracy introduced by the use of
floating-point numbers is tolerable). This property allows data
to be aggregated and re-aggregated without any loss of original
count information. To avoid confusion in interpretation of the
aggregated data, all the counters for a set of given original
Flows SHOULD be distributed via the same method.</t>
</section>
<section title="Time Composition" anchor="sec-timecomp">
<t>Time Composition as in section 5.4 of <xref
target="RFC5982"/> (or interval combination) is a special case
of aggregation, where interval distribution imposes longer
intervals on Flows with matching keys and "chained" start and
end times, without any key reduction, in order to join
long-lived Flows which may have been split (e.g., due to an
active timeout shorter than the Flow.) Here, no Key aggregation
is applied, and the Aggregation Interval is chosen on a per-Flow
basis to cover the interval spanned by the set of aggregated
Flows. This may be applied alone in order to normalize split
Flows, or in combination with other aggregation functions in
order to obtain more accurate original Flow counts.</t>
</section>
</section>
<section title="Spatial Aggregation of Flow Keys" anchor="sec-iap-key">
<t>Key aggregation generates a new Flow Key for the Aggregated
Flows from the original Flow Keys, non-Key fields in the original
Flows, or from correlation of the original Flow information with
some external source. There are two basic operations here. First,
Aggregated Flow Keys may be derived directly from original Flow
Keys through reduction, or the dropping of fields or precision in
the original Flow Keys. Second, an Aggregated Flow Key may be
derived through replacement, e.g. by removing one or more fields
from the original Flow and replacing them with a fields derived
from the removed fields. Replacement may refer to external
information (e.g., IP to AS number mappings). Replacement need not
replace only key fields. For example, consider an application
which aggregates flows by packet count (i.e., generating an
Aggregated Flow for all one-packet Flows, one for all two-packet
Flows, and so on). This application would promote the packet count
to a Flow Key field.</t>
<t>Key aggregation may also result in the addition of new non-Key
fields to the Aggregated Flows, namely original Flow counters and
unique reduced key counters; these are treated in more detail in
<xref target="sec-flowcount"/> and <xref target="sec-distinct"/>,
respectively.</t>
<t>In any key aggregation operation, reduction and/or replacement
may be applied any number of times in any order. Which of these
operations are supported by a given implementation is
implementation- and application-dependent. Key aggregation may
aggregate original Flows with different sets of Flow Key fields;
only the Flow Keys of the resulting Aggregated Flows of any given
Key aggregation operation need contain the same set of fields.</t>
<figure title="Illustration of key aggregation by reduction" anchor="keyagg-simple-fig">
<artwork><![CDATA[
Original Flow Key
+---------+---------+----------+----------+-------+-----+
| src ip4 | dst ip4 | src port | dst port | proto | tos |
+---------+---------+----------+----------+-------+-----+
| | | | | |
retain mask /24 X X X X
V V
+---------+-------------+
| src ip4 | dst ip4 /24 |
+---------+-------------+
Aggregated Flow Key (by source address and destination class-C)
]]></artwork>
</figure>
<t><xref target="keyagg-simple-fig"/> illustrates an example
reduction operation, aggregation by source address and
destination class C network. Here, the port, protocol, and
type-of-service information is removed from the Flow Key, the
source address is retained, and the destination address is masked
by dropping the low 8 bits.</t>
<figure title="Illustration of key aggregation by reduction and replacement" anchor="keyagg-replace-fig">
<artwork><![CDATA[
Original Flow Key
+---------+---------+----------+----------+-------+-----+
| src ip4 | dst ip4 | src port | dst port | proto | tos |
+---------+---------+----------+----------+-------+-----+
| | | | | |
+-------------------+ X X X X
| ASN lookup table |
+-------------------+
V V
+---------+---------+
| src asn | dst asn |
+---------+---------+
Aggregated Flow Key (by source and dest ASN)
]]></artwork>
</figure>
<t><xref target="keyagg-replace-fig"/> illustrates an example
reduction and replacement operation, aggregation by source and
destination ASN without ASN information available in the original
Flow. Here, the port, protocol, and type-of-service information is
removed from the Flow Key, while the source and destination
addresses are run though an IP address to ASN lookup table, and
the Aggregated Flow Key is made up of the resulting source and
destination ASNs.</t>
<section title="Counting Distinct Key Values" anchor="sec-distinct">
<t>One common case in aggregation is counting distinct key
values that were reduced away during key aggregation. The most
common use case for this is counting distinct hosts per Flow
Key; for example, in host characterization or anomaly detection,
distinct sources per destination or distinct destinations per
source are common metrics. These new non-Ley fields are added
during key aggregation.</t>
<t>For such applications, Information Elements for distinct
counts of IPv4 and IPv6 addresses are defined in <xref
target="sec-ex-distinct"/>. These are named
distinctCountOf(KeyName). Additional such Information Elements
SHOULD be registered with IANA on an as-needed basis.</t>
</section>
<section title="Counting Original Flows" anchor="sec-flowcount">
<t>When aggregating multiple original Flows into an Aggregated
Flow, it is often useful to know how many original Flows are
present in the Aggregated Flow. This document introduces four
new information elements in <xref target="sec-ex-flowcount"/> to
export these counters.</t>
<t>There are two possible ways to count original Flows, which
we call here conservative and non-conservative. Conservative
flow counting has the property that each original Flow
contributes exactly one to the total flow count within a set of
aggregated Flows. In other words, conservative flow counters are
distributed just as any other counter during interval
distribution, except each original Flow is assumed to have a
flow count of one. When a count for an original Flow must be
distributed across a set of Aggregated Flows, and a distribution
method is used which does not account for that original Flow
completely within a single Aggregated Flow, conservative flow
counting requires a fractional representation.</t>
<t>By contrast, non-conservative flow counting is used to count
how many contributing Flows are represented in an Aggregated
Flow. Flow counters are not distributed in this case. An
original Flow which is present within N Aggregated Flows would
add N to the sum of non-conservative flow counts, one to each
Aggregated Flow. In other words, the sum of conservative flow
counts over a set of Aggregated Flows is always equal to the
number of original Flows, while the sum of non-conservative flow
counts is strictly greater than or equal to the number of
original Flows.</t>
<t>For example, consider Flows A, B, and C as illustrated in
<xref target="intdist-fig"/>. Assume that the key aggregation
step aggregates the keys of these three Flows to the same
aggregated Flow Key, and that start interval counter
distribution is in effect. The conservative flow count for
interval 0 is 3 (since Flows A, B, and C all begin in this
interval), and for the other two intervals is 0. The
non-conservative flow count for interval 0 is also 3 (due to the
presence of Flows A, B, and C), for interval 1 is 2 (Flows B and
C), and for interval 2 is 1 (Flow C). The sum of the
conservative counts 3 + 0 + 0 = 3, the number of original Flows;
while the sum of the non-conservative counts 3 + 2 + 1 = 6.</t>
<t>Note that the active and inactive timeouts used to generate
original Flows, as well as the cache policy used to generate
those Flows, have an effect on how meaningful either the
conservative or non-conservative flow count will be during
aggregation. In general, all the original Exporters producing
original Flows to be aggregated SHOULD be aggregated using
caches configured identically or similarly. Original Exporters
using the IPFIX Configuration Model SHOULD be configured to
export Flows with equal or similar activeTimeout and
inactiveTimeout configuration values, and the same cacheMode, as
defined in section 4.3 of <xref
target="I-D.ietf-ipfix-configuration-model"/>.</t>
</section>
</section>
<section title="Spatial Aggregation of Non-Key Fields" anchor="sec-iap-value">
<t>Aggregation operations may also lead to the addition of value
fields demoted from key fields, or derived from other value fields
in the original Flows. Specific cases of this are treated in the
subsections below. </t>
<section title="Counter Statistics" anchor="sec-countstats">
<t>Some applications of aggregation may benefit from
computing different statistics than those native to each
non-key field (i.e., union for flags, sum for counters). For
example, minimum and maximum packet counts per Flow, mean
bytes per packet per aggregated Flow, and so on. Certain
Information Elements for these applications are already
provided in the IANA IPFIX Information Elements registry
(http://www.iana.org/assignments/ipfix/ipfix.html (e.g.
minimumIpTotalLength).</t>
<t>A complete specification of additional aggregate counter
statistics is outside the scope of this document, and should
be added in the future to the IANA IPFIX Information
Elements registry on a per-application, as-needed basis.</t>
</section>
</section>
<section title="Aggregation Combination" anchor="sec-iap-combo">
<t>Interval distribution and key aggregation together may generate
multiple partially aggregated Flows covering the same time
interval with the same Flow Key. The process of combining these
partially aggregated Flows into a single Aggregated Flow is called
aggregation combination. In general, non-Key values from multiple
contributing Flows are combined using the same operation by which
values are combined from packets to form Flows for each
Information Element. Counters are summed, averages are
averaged, flags are unioned, and so on.</t>
</section>
</section>
<section title="Additional Considerations and Special Cases in Flow Aggregation">
<section title="Exact versus Approximate Counting during Aggregation"
anchor="sec-lowfi">
<t>In certain circumstances, particularly involving aggregation by
devices with limited resources, and in situations where exact
aggregated counts are less important than relative magnitudes
(e.g. driving graphical displays), counter distribution during key
aggregation may be performed by approximate counting means (e.g.
Bloom filters). The choice to use approximate counting is
implementation- and application-dependent.</t>
<!-- <t>In certain cases, the magnitude of error for a given
Information Element due to approximate counting may be known. An
Exporting Process MAY use the Error Magnitude Options Template
defined in <xref target="sec-ex-error"/> to export this
information.</t> -->
</section>
<section title="Considerations for Aggregation of Sampled Flows">
<t>The accuracy of Aggregated Flows may also be affected by
sampling of the original Flows, or sampling of packets making up
the original Flows. The effect of sampling on flow aggregation is
still an open research question. However, to maximize the
comparability of Aggregated Flows, aggregation of sampled Flows
SHOULD only use original Flows sampled using the same sampling
rate and sampling algorithm, or Flows created from packets sampled
using the same sampling rate and sampling algorithm. For more on
packet sampling within IPFIX, see <xref target="RFC5476"/>. For
more on Flow sampling within the IPFIX Mediator Framework, see
<xref target="I-D.ietf-ipfix-flow-selection-tech"/>.</t>
</section>
</section>
<section title="Export of Aggregated IP Flows using IPFIX" anchor="sec-export">
<t>In general, Aggregated Flows are exported in IPFIX as any normal Flow. However, certain aspects of Aggregated Flow export benefit from additional guidelines, or new Information Elements to represent aggregation metadata or information generated during aggregation. These are detailed in the following subsections.</t>
<section title="Time Interval Export">
<t>Since an Aggregated Flow is simply a Flow, the existing
timestamp Information Elements in the IPFIX Information Model
(e.g., flowStartMilliseconds, flowEndNanoseconds) are sufficient
to specify the time interval for aggregation. Therefore, this
document specifies no new aggregation-specific Information
Elements for exporting time interval information.</t>
<t>Each Aggregated Flow SHOULD contain both an interval start and
interval end timestamp. If an exporter of Aggregated Flows omits
the interval end timestamp from each Aggregated Flow, the time
interval for Aggregated Flows within an Observation Domain and
Transport Session MUST be regular and constant.
However, note that this approach might lead to interoperability
problems when exporting Aggregated Flows to non-aggregation-aware
Collecting Processes and downstream analysis tasks; therefore, an
Exporting Process capable of exporting only interval start
timestamps MUST provide a configuration option to export interval
end timestamps as well.</t>
</section>
<section title="Flow Count Export" anchor="sec-ex-flowcount">
<t>The following four Information Elements are defined to count original Flows as discussed in <xref target="sec-flowcount"/>.</t>
<section title="originalFlowsPresent" anchor="ie-noncon-flowcount">
<list style="hanging">
<t hangText="Description: ">
The non-conservative count of original Flows contributing to
this Aggregated Flow. Non-conservative counts need not sum to
the original count on re-aggregation.
</t>
<t hangText="Abstract Data Type: ">unsigned64</t>
<t hangText="ElementId: ">TBD1</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="originalFlowsInitiated" anchor="ie-con-flowstartcount">
<list style="hanging">
<t hangText="Description: ">
The conservative count of original Flows whose first packet is
represented within this Aggregated Flow. Conservative counts
must some to the original count on re-aggregation.
</t>
<t hangText="Abstract Data Type: ">unsigned64</t>
<t hangText="ElementId: ">TBD2</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="originalFlowsCompleted" anchor="ie-con-flowendcount">
<list style="hanging">
<t hangText="Description: ">
The conservative count of original Flows whose last packet is
represented within this Aggregated Flow. Conservative counts
must some to the original count on re-aggregation.
</t>
<t hangText="Abstract Data Type: ">unsigned64</t>
<t hangText="ElementId: ">TBD3</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="originalFlows" anchor="ie-con-flowcount">
<list style="hanging">
<t hangText="Description: ">
The conservative count of original Flows contributing to this
Aggregated Flow; may be distributed via any of the methods
described in <xref target="sec-distro"/>.
</t>
<t hangText="Abstract Data Type: ">float64</t>
<t hangText="ElementId: ">3</t>
<t hangText="Status: ">Current</t>
</list>
</section>
</section>
<section title="Distinct Host Export" anchor="sec-ex-distinct">
<t>The following four Information Elements represent the distinct counts of source and destination addresses for IPv4 and IPv6, used to exporting distinct host counts reduced away during key aggregation.</t>
<section title="distinctCountOfSourceIPv4Address" anchor="ie-dsip4">
<list style="hanging">
<t hangText="Description: ">The count of distinct source IPv4 address values for original Flows contributing to this Aggregated Flow.</t>
<t hangText="Abstract Data Type: ">unsigned32</t>
<t hangText="ElementId: ">TBD6</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="distinctCountOfDestinationIPv4Address" anchor="ie-ddip4">
<list style="hanging">
<t hangText="Description: ">The count of distinct destination IPv4 address values for original Flows contributing to this Aggregated Flow.</t>
<t hangText="Abstract Data Type: ">unsigned32</t>
<t hangText="ElementId: ">TBD7</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="distinctCountOfSourceIPv6Address" anchor="ie-dsip6">
<list style="hanging">
<t hangText="Description: ">The count of distinct source IPv6 address values for original Flows contributing to this Aggregated Flow.</t>
<t hangText="Abstract Data Type: ">unsigned64</t>
<t hangText="ElementId: ">TBD8</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="distinctCountOfDestinationIPv6Address" anchor="ie-ddip6">
<list style="hanging">
<t hangText="Description: ">The count of distinct destination IPv6 address values for original Flows contributing to this Aggregated Flow.</t>
<t hangText="Abstract Data Type: ">unsigned64</t>
<t hangText="ElementId: ">TBD9</t>
<t hangText="Status: ">Current</t>
</list>
</section>
</section>
<section title="Aggregate Counter Distribution Export" anchor="sec-ex-distro">
<t>When exporting counters distributed among Aggregated Flows, as
described in <xref target='sec-distro'/>, the Exporting Process MAY
export an Aggregate Counter Distribution Record for each Template
describing Aggregated Flow records; this Options Template is
described below. It uses the valueDistributionMethod Information
Element, also defined below. Since in many cases distribution is
simple, accounting the counters from contributing Flows to the
first Interval to which they contribute, this is default
situation, for which no Aggregate Counter Distribution Record is
necessary; Aggregate Counter Distribution Records are only
applicable in more exotic situations, such as using an Aggregation
Interval smaller than the durations of original Flows.</t>
<section title="Aggregate Counter Distribution Options Template">
<t>This Options Template defines the Aggregate Counter
Distribution Record, which allows the binding of a value
distribution method to a Template ID. This is used to signal
to the Collecting Process how the counters were distributed.
The fields are as below:
<texttable>
<ttcol align="left">IE</ttcol>
<ttcol align="left">Description</ttcol>
<c>templateId [scope]</c>
<c>
The Template ID of the Template defining the Aggregated
Flows to which this distribution option applies. This
Information Element MUST be defined as a Scope Field.
</c>
<c>valueDistributionMethod</c>
<c>
The method used to distribute the counters for the
Aggregated Flows defined by the associated Template.
</c>
</texttable></t>
</section>
<section title="valueDistributionMethod Information Element" anchor="ie-errmag">
<list style="hanging">
<t hangText="Description: ">
A description of the method used to distribute the
counters from contributing Flows into the Aggregated
Flow records described by an associated Template. The
method is deemed to apply to all the non-key
Information Elements in the referenced Template for
which value distribution is a valid operation; if the
originalFlowsInitiated and/or originalFlowsCompleted
Information Elements appear in the Template, they are
not subject to this distribution method, as they each
infer their own distribution method. The distribution
methods are taken from <xref target='sec-distro'/> and
encoded as follows:
<texttable>
<ttcol align="left">Value</ttcol>
<ttcol align="left">Description</ttcol>
<c>1</c><c>Start Interval: The counters for an
original Flow are added to the counters of the
appropriate Aggregated Flow containing the start time
of the original Flow. This should be assumed the
default if value distribution information is not
available at a Collecting Process for an Aggregated
Flow.</c>
<c>2</c><c>End Interval: The counters for an original
Flow are added to the counters of the appropriate
Aggregated Flow containing the end time of the
original Flow.</c>
<c>3</c><c>Mid Interval: The counters for an original
Flow are added to the counters of a single appropriate
Aggregated Flow containing some timestamp between
start and end time of the original Flow.</c>
<c>4</c><c>Simple Uniform Distribution: Each counter
for an original Flow is divided by the number of time
intervals the original Flow covers (i.e., of
appropriate Aggregated Flows sharing the same Flow
Key), and this number is added to each corresponding
counter in each Aggregated Flow.</c>
<c>5</c><c>Proportional Uniform Distribution: Each
counter for an original Flow is divided by the number
of time _units_ the original Flow covers, to derive a
mean count rate. This mean count rate is then
multiplied by the number of time units in the
intersection of the duration of the original Flow and
the time interval of each Aggregated Flow. This is
like simple uniform distribution, but accounts for the
fractional portions of a time interval covered by an
original Flow in the first and last time interval.</c>
<c>6</c><c>Simulated Process: Each counter of the
original Flow is distributed among the intervals of
the Aggregated Flows according to some function the
Aggregation Process uses based upon properties of
Flows presumed to be like the original Flow. This is
essentially an assertion that the Aggregation Process
has no direct packet timing information but is
nevertheless not using one of the other simpler
distribution methods. The Aggregation Process
specifically makes no assertion as to the correctness
of the simulation.</c>
<c>7</c><c>Direct: The Aggregation Process has access
to the original packet timings from the packets making
up the original Flow, and uses these to distribute or
recalculate the counters.</c>
</texttable>
</t>
<t hangText="Abstract Data Type: ">unsigned8</t>
<t hangText="ElementId: ">TBD5</t>
<t hangText="Status: ">Current</t>
</list>
</section>
</section>
<!--
<section title="Error Magnitude Export" anchor="sec-ex-error">
<section title="errorMagnitude Information Element" anchor="ie-errmag">
<list style="hanging">
<t hangText="Description: ">
The approximate magnitude of the error induced by the
Intermediate Aggregation Process in the values of the
associated Information Element, as a proportion of the
range of values covered by the Information Element;
SHOULD be associated with an informationElementId and
optional templateId as scope in an Options
Template.</t>
<t hangText="Abstract Data Type: ">float64</t>
<t hangText="ElementId: ">TBD6</t>
<t hangText="Status: ">Current</t>
</list>
</section>
<section title="Error Magnitude Options Template">
<t>[TODO: define options template]</t>
</section>
</section>
-->
</section>
<section title="Examples">
<t>In these examples, the same data, described by the same template, will be aggregated multiple different ways; this illustrates the various different functions which could be implemented by Intermediate Aggregation Processes. Templates are shown in iespec format as introduced in <xref target="I-D.trammell-ipfix-ie-doctors"/>. The source data format is a simplified flow: timestamps, traditional 5-tuple, and octet count. The template is shown in <xref target="ex-tmpl-in"/>.</t>
<figure title="Input template for examples" anchor="ex-tmpl-in">
<artwork><![CDATA[
flowStartMilliseconds
flowEndMilliseconds
sourceIPv4Address
destinationIPv4Address
sourceTransportPort
destinationTransportPort
protocolIdentifier
octetDeltaCount
]]></artwork>
</figure>
<t>The data records given as input to the examples in this section are shown below, in the format "flowStartMilliseconds-flowEndMilliseconds sourceIPv4Address:sourceTransportPort -> destinationIPv4Address:destinationTransportPort (protocolIdentifier) octetDeltaCount"; timestamps are given in H:MM:SS.sss format.</t>
<figure title="Input data for examples" anchor="ex-data-in">
<artwork><![CDATA[
9:00:00.138-9:00:00.138 192.0.2.2:47113 -> 192.0.2.131:53 (17) 119
9:00:03.246-9:00:03.246 192.0.2.2:22153 -> 192.0.2.131:53 (17) 83
9:00:00.478-9:00:03.486 192.0.2.2:52420 -> 198.51.100.2:443 (6) 1637
9:00:07.172-9:00:07.172 192.0.2.3:56047 -> 192.0.2.131:53 (17) 111
9:00:07.309-9:00:14.861 192.0.2.3:41183 -> 198.51.100.67:80 (6) 16838
9:00:03.556-9:00:19.876 192.0.2.2:17606 -> 198.51.100.68:80 (6) 11538
9:00:25.210-9:00:25.210 192.0.2.3:47113 -> 192.0.2.131:53 (17) 119
9:00:26.358-9:00:30.198 192.0.2.3:48458 -> 198.51.100.133:80 (6) 2973
9:00:29.213-9:01:00.061 192.0.2.4:61295 -> 198.51.100.2:443 (6) 8350
9:04:00.207-9:04:04.431 203.0.113.3:41256 -> 198.51.100.133:80 (6) 778
9:03:59.624-9:04:06.984 203.0.113.3:51662 -> 198.51.100.3:80 (6) 883
9:06:56.813-9:06:59.821 203.0.113.3:52572 -> 198.51.100.2:443 (6) 1637
9:06:30.565-9:07:00.261 203.0.113.3:49914 -> 197.51.100.133:80 (6) 561
9:06:55.160-9:07:05.208 192.0.2.2:50824 -> 198.51.100.2:443 (6) 1899
9:06:49.322-9:07:05.322 192.0.2.3:34597 -> 198.51.100.3:80 (6) 1284
9:07:05.849-9:07:09.625 203.0.113.3:58907 -> 198.51.100.4:80 (6) 2670
9:10:45.161-9:10:45.161 192.0.2.4:22478 -> 192.0.2.131:53 (17) 75
9:10:45.209-9:11:01.465 192.0.2.4:49513 -> 198.51.100.68:80 (6) 3374
9:10:57.094-9:11:00.614 192.0.2.4:64832 -> 198.51.100.67:80 (6) 138
9:10:59.770-9:11:02.842 192.0.2.3:60833 -> 198.51.100.69:443 (6) 2325
9:13:53.933-9:14:06.605 192.0.2.2:19638 -> 198.51.100.3:80 (6) 2869
9:13:02.864-9:14:08.720 192.0.2.3:40429 -> 198.51.100.4:80 (6) 18289
]]></artwork>
</figure>
<section title="Traffic Time-Series per Source" anchor="ex-srcip">
<t>Aggregating flows by source IP address in time series (i.e., with a
regular interval) can be used in subsequent heavy-hitter analysis and as
a source parameter for statistical anomaly detection techniques. Here,
the Intermediate Aggregation Process imposes an interval, aggregates the
key to remove all key fields other than the source IP address, then
combines the result into a stream of Aggregated Flows. For simplicity,
the imposed interval of 30 minutes is defined to be larger than the
maximum active timeout of the original Flows; counter distribution will
be added to this example below in <xref target="ex-distro"/>.</t>
<t>In this example the partially aggregated Flows after each conceptual
operation in the Intermediate Aggregation Process are shown. These are
meant to be illustrative of the conceptual operations only, and not to
suggest an implementation (indeed, the example shown here would not
necessarily be the most efficient method for performing these
operations). Subsequent examples will omit the partially aggregated
Flows for brevity.</t>
<t>The input to this process could be any Flow Record containing a
source IP address and octet counter; consider for this example the
template and data from the introduction. The Intermediate Aggregation
Process would then output records containing just timestamps, source IP,
and octetDeltaCount, as in <xref target="ex-srcip-tmpl-out"/>.</t>
<figure title="Output template for time series per source" anchor="ex-srcip-tmpl-out">
<artwork><![CDATA[
flowStartMilliseconds
flowEndMilliseconds
sourceIPv4Address
octetDeltaCount
]]></artwork>
</figure>
<t>Assume the goal is to get 5-minute time series of octet counts per source IP address. The aggregation operations would then be arranged as in <xref target="ex-srcip-iap"/>.</t>
<figure title="Aggregation operations for time series per source" anchor="ex-srcip-iap"><artwork><![CDATA[
original Flows
|
V
+-----------------------+
| interval distribution |
| * impose uniform |
| 300s time interval |
+-----------------------+
|
| partially aggregated Flows
V
+------------------------+
| key aggregation |
| * reduce key to only |
| sourceIPv4Address |
+------------------------+
|
| partially aggregated Flows
V
+-------------------------+
| aggregate combination |
| * sum octetDeltaCount |
+-------------------------+
|
V
Aggregated Flows
partially aggregated Flows
]]></artwork></figure>
<t>After the interval distribution step, only the time intervals have changed; the partially aggregated Flows are shown in <xref target="ex-srcip-pa-int"/>.</t>
<figure title="Partially aggregated Flows: intervals imposed" anchor="ex-srcip-pa-int">
<artwork><![CDATA[
9:00:00.000-9:05:00.000 192.0.2.2:47113 -> 192.0.2.131:53 (17) 119
9:00:00.000-9:05:00.000 192.0.2.2:22153 -> 192.0.2.131:53 (17) 83
9:00:00.000-9:05:00.000 192.0.2.2:52420 -> 198.51.100.2:443 (6) 1637
9:00:00.000-9:05:00.000 192.0.2.3:56047 -> 192.0.2.131:53 (17) 111
9:00:00.000-9:05:00.000 192.0.2.3:41183 -> 198.51.100.67:80 (6) 16838
9:00:00.000-9:05:00.000 192.0.2.2:17606 -> 198.51.100.68:80 (6) 11538
9:00:00.000-9:05:00.000 192.0.2.3:47113 -> 192.0.2.131:53 (17) 119
9:00:00.000-9:05:00.000 192.0.2.3:48458 -> 198.51.100.133:80 (6) 2973
9:00:00.000-9:05:00.000 192.0.2.4:61295 -> 198.51.100.2:443 (6) 8350
9:00:00.000-9:05:00.000 203.0.113.3:41256 -> 198.51.100.133:80 (6) 778
9:00:00.000-9:05:00.000 203.0.113.3:51662 -> 198.51.100.3:80 (6) 883
9:05:00.000-9:10:00.000 203.0.113.3:52572 -> 198.51.100.2:443 (6) 1637
9:05:00.000-9:10:00.000 203.0.113.3:49914 -> 197.51.100.133:80 (6) 561
9:05:00.000-9:10:00.000 192.0.2.2:50824 -> 198.51.100.2:443 (6) 1899
9:05:00.000-9:10:00.000 192.0.2.3:34597 -> 198.51.100.3:80 (6) 1284
9:05:00.000-9:10:00.000 203.0.113.3:58907 -> 198.51.100.4:80 (6) 2670
9:10:00.000-9:15:00.000 192.0.2.4:22478 -> 192.0.2.131:53 (17) 75
9:10:00.000-9:15:00.000 192.0.2.4:49513 -> 198.51.100.68:80 (6) 3374
9:10:00.000-9:15:00.000 192.0.2.4:64832 -> 198.51.100.67:80 (6) 138
9:10:00.000-9:15:00.000 192.0.2.3:60833 -> 198.51.100.69:443 (6) 2325
9:10:00.000-9:15:00.000 192.0.2.2:19638 -> 198.51.100.3:80 (6) 2869
9:10:00.000-9:15:00.000 192.0.2.3:40429 -> 198.51.100.4:80 (6) 18289
]]></artwork>
</figure>
<t>After the key aggregation step, all the parts of the flow key except the source IP address have been discarded, as shown in <xref target="ex-srcip-pa-key"/>. This leaves duplicate partially aggregated Flows to be combined the final operation.</t>
<figure title="Partially aggregated Flows: key aggregation" anchor="ex-srcip-pa-key">
<artwork><![CDATA[
9:00:00.000-9:05:00.000 192.0.2.2 119
9:00:00.000-9:05:00.000 192.0.2.2 83
9:00:00.000-9:05:00.000 192.0.2.2 1637
9:00:00.000-9:05:00.000 192.0.2.3 111
9:00:00.000-9:05:00.000 192.0.2.3 16838
9:00:00.000-9:05:00.000 192.0.2.2 11538
9:00:00.000-9:05:00.000 192.0.2.3 119
9:00:00.000-9:05:00.000 192.0.2.3 2973
9:00:00.000-9:05:00.000 192.0.2.4 8350
9:00:00.000-9:05:00.000 203.0.113.3 778
9:00:00.000-9:05:00.000 203.0.113.3 883
9:05:00.000-9:10:00.000 203.0.113.3 1637
9:05:00.000-9:10:00.000 203.0.113.3 561
9:05:00.000-9:10:00.000 192.0.2.2 1899
9:05:00.000-9:10:00.000 192.0.2.3 1284
9:05:00.000-9:10:00.000 203.0.113.3 2670
9:10:00.000-9:15:00.000 192.0.2.4 75
9:10:00.000-9:15:00.000 192.0.2.4 3374
9:10:00.000-9:15:00.000 192.0.2.4 138
9:10:00.000-9:15:00.000 192.0.2.3 2325
9:10:00.000-9:15:00.000 192.0.2.2 2869
9:10:00.000-9:15:00.000 192.0.2.3 18289
]]></artwork>
</figure>
<t>Aggregate combination sums the counters per key and interval; the summations of the first two keys and intervals are shown in detail in <xref target="ex-srcip-sum"/>.</t>
<figure title="Summation during aggregate combination" anchor="ex-srcip-sum">
<artwork><![CDATA[
9:00:00.000-9:05:00.000 192.0.2.2 119
9:00:00.000-9:05:00.000 192.0.2.2 83
9:00:00.000-9:05:00.000 192.0.2.2 1637
+ 9:00:00.000-9:05:00.000 192.0.2.2 11538
-----
= 9:00:00.000-9:05:00.000 192.0.2.2 13377
9:00:00.000-9:05:00.000 192.0.2.3 111
9:00:00.000-9:05:00.000 192.0.2.3 16838
9:00:00.000-9:05:00.000 192.0.2.3 119
+ 9:00:00.000-9:05:00.000 192.0.2.3 2973
-----
= 9:00:00.000-9:05:00.000 192.0.2.3 20041
]]></artwork>
</figure>
<t>Applying this to each set of partially aggregated Flows to produce the final Aggregated Flows shown in <xref target="ex-srcip-agg"/>m to be exported by the template in <xref target="ex-srcip-tmpl-out"/>.</t>
<figure title="Aggregated Flows " anchor="ex-srcip-agg">
<artwork><![CDATA[
9:00:00.000-9:05:00.000 192.0.2.2 13377
9:00:00.000-9:05:00.000 192.0.2.3 20041
9:00:00.000-9:05:00.000 192.0.2.4 8350
9:00:00.000-9:05:00.000 203.0.113.3 1661
9:05:00.000-9:10:00.000 192.0.2.2 1899
9:05:00.000-9:10:00.000 192.0.2.3 1284
9:05:00.000-9:10:00.000 203.0.113.3 4868
9:10:00.000-9:15:00.000 192.0.2.2 2869
9:10:00.000-9:15:00.000 192.0.2.3 20594
9:10:00.000-9:15:00.000 192.0.2.4 3587
]]></artwork>
</figure>
</section>
<section title="Core Traffic Matrix">
<t>Aggregating flows by source and destination autonomous system number
in time series is used to generate core traffic matrices. The core
traffic matrix provides a view of the state of the routes within a
network, and can be used for long-term planning of changes to network
design based on traffic demand. Here, imposed time intervals are
generally much longer than active flow timeouts. The traffic matrix is
reported in terms of octets, packets, and flows, as each of these values
may have a subtly different effect on capacity planning.</t>
<t>This example demonstrates key aggregation using derived keys and
Original Flow counting. While some original Flows may be generated by
Exporting Processes on forwarding devices, and therefore contain the
bgpSourceAsNumber and bgpDestinationAsNumber Information Elements,
original Flows from Exporting Processes on dedicated measurement devices
will contain only a destinationIPv[46]Address. For these flows, the
Mediator must look up a next hop AS from a IP to AS table, replacing
source and destination addresses with AS numbers.</t>
<t>[TODO: complete example. show AS map, output templates, and
processing in IAP.]</t>
</section>
<section title="Distinct Source Count per Destination Endpoint">
<t>Aggregating flows by destination address and port, and counting
distinct sources aggregated away, can be used as part of passive service
inventory and host characterization approaches. This example shows
aggregation as an analysis technique, performed on source data stored in
an IPFIX File. As the Transport Session in this File is bounded, removal
of all timestamp information allows summarization of the entire time
interval contained within the interval. Removal of timing information
during interval imposition is equivalent to an infinitely long imposed
time interval. This demonstrates both how infinite intervals work, and
how unique counters work.</t>
<t>[TODO: complete example. show output templates and
processing in IAP.]</t>
</section>
<section title="Traffic Time-Series per Source with Counter Distribution" anchor="ex-distro">
<t>Returning to the example in <xref target="ex-srcip"/>, consider a case
where aggregation by the maximum active timeout, here 30 minutes, is
incompatible with the processing interval, here defined to be 5 minutes.
For this case, flows longer than 5 minutes must have their counters
distributed. This example demonstrates counter distribution metadata
export.</t>
<t>[TODO: complete example. show output metadata and
processing in IAP.]</t>
</section>
</section>
<section title="Security Considerations">
<t>[TODO]</t>
</section>
<section title="IANA Considerations">
<t>This document specifies the creation of twelve new IPFIX
Information Elements in the IPFIX Information Element registry located
at http://www.iana.org/assignments/ipfix, as defined in <xref
target="sec-export"></xref> above. IANA has assigned Information
Element numbers to these Information Elements, and entered them into
the registry.</t>
<t>[NOTE for IANA: The text TBDn should be replaced with the
respective assigned Information Element numbers where they appear in
this document. Note that the originalFlows Information Element has
been assigned the number 3, as it is compatible with the corresponding
existing (reserved) NetFlow v9 Information Element. Other Information
Element numbers should be assigned outside the NetFlow V9
compatibility range, as these Information Elements are not supported
by NetFlow V9.]</t>
</section>
<section title="Acknowledgments">
<t>This work is materially supported by the European Union Seventh
Framework Programme under grant agreement 257315 (DEMONS).</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5101" ?>
<?rfc include="reference.RFC.5102" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3917" ?>
<?rfc include="reference.RFC.5103" ?>
<?rfc include="reference.RFC.5153" ?>
<?rfc include="reference.RFC.5470" ?>
<?rfc include="reference.RFC.5472" ?>
<?rfc include="reference.RFC.5476" ?>
<?rfc include="reference.RFC.5610" ?>
<?rfc include="reference.RFC.5655" ?>
<?rfc include="reference.RFC.5835" ?>
<?rfc include="reference.RFC.5982" ?>
<?rfc include="reference.I-D.ietf-ipfix-anon" ?>
<?rfc include="reference.I-D.ietf-ipfix-mediators-framework" ?>
<?rfc include="reference.I-D.claise-ipfix-mediation-protocol" ?>
<?rfc include="reference.I-D.trammell-ipfix-ie-doctors" ?>
<?rfc include="reference.I-D.ietf-ipfix-configuration-model" ?>
<?rfc include="reference.I-D.ietf-ipfix-flow-selection-tech" ?>
</references>
<!-- <section title="Text to be removed">
<section title="A general operational model for IP Flow aggregation" anchor="sec-model">
<t>An Intermediate Aggregation Process consumes original Flows and
exports Aggregated Flows, as defined in <xref
target="sec-terminology"/>. While this document does not define an
implementation of an Intermediate Aggregation Process further than
this, or the Aggregation Functions that it applies, it can be
helpful to partially decompose this function into a set of common
operations, in order to more fully examine the effects these
operations have.</t>
<t>Aggregation is composed of three general types of operations on
original Flows: temporal aggregation operations, which impose a
time interval, called here "interval distribution"; spatial
aggregation operations on Flow Keys, which derive a new Flow Key
for the Aggregated Flows from the original Flow information,
called here "key aggregation"; and combination operations on
non-Key fields which take the partially-aggregated results of
these operations and produce Aggregated Flows from them, here
called "value aggregation". Most aggregation functions will
perform each of these types of operations.</t>
<t>Interval distribution is the imposition of a time interval onto
an original Flow. The interval may be externally imposed, or
derived from the timestamps from the set of original Flows or
resulting aggregated Flows. Note that interval distribution may
lead to an original Flow contributing to multiple aggregated
Flows, if the original Flow's time interval crosses at least one
boundary between Aggregation Intervals. Interval distribution is
described in more detail in <xref target="sec-iap-interval"/>.</t>
<t>Key aggregation, the derivation of Flow Keys for Aggregated
Flows from original Flow information, is made up of two
operations: reduction and replacement. Reduction removes
Information Elements from the original Flow Key, or otherwise
constrains the space of values in the Flow Key (e.g., by replacing
IP addresses with /24 CIDR blocks). In replacement, Information
Elements derived from fields in the original Flow itself may be
added to the Flow Key. Both of these modifications may result in
multiple original Flows contributing to the same Aggregated Flow.
Key aggregation is described in more detail in <xref
target="sec-keyagg"/>.</t>
<t>Interval distribution and key aggregation together may generate
multiple partially aggregated Flows covering the same time
interval with the same Flow Key; the values must be combined to
produce a single Aggregates Flow. This is called value
aggregation, and is covered in detail in <xref
target="sec-valagg"/>.</t>
<t>As a result of this final combination and distribution,an
Aggregation Function produces at most one Aggregated Flow
resulting from a set of original Flows for a given Aggregated Flow
Key and Aggregation Interval.</t>
<t>This general model is illustrated in the figure below. Note
that within an implementation, these steps may occur in any order,
and indeed be combined together in any way.</t>
</section>
<section title="Key Aggregation" anchor="sec-keyagg">
</section>
<section title="Value Aggregation" anchor="sec-valagg">>
</section>
<section title="A Note on Spatio-Temporal Dependency in Aggregation">
<t>In general, aggregation of data bearing time
information can take place in time (by grouping the original
records by time) or in space (by grouping the original records by
some other dimension; in the case of IP Flows, this would
generally be a flow key.</t>
<t>Temporal aggregation is treated in <xref
target="I-D.ietf-ipfix-mediators-framework"/> in section 5.3.2.3,
"Intermediate Aggregation Process", as "[m]erging a set of Data
Records within a certain time period into one Flow Record by
summing up the counters where appropriate," as well as in the
definition of "temporal composition, wherein "multiple consecutive
Flow Records with identical Flow Key values are merged into a
single Flow Record of longer Flow duration if they arrive within a
certain time interval." Spatial aggregation, from the same
section, is treated as "spatial composition", wherein "Data
Records sharing common properties are merged into one Flow Record
within a certain time period."</t>
<t>These definitions do not address the interdependency
among temporal and spatial aggregation of IPFIX Flows. The issue
arises because an IP Flow, as defined in <xref target="RFC5101"/>,
has three types of properties: flow keys, which "define" the
properties common to all packets in the Flow; flow values or
non-key fields, which describe the Flow itself; and the time
interval of the Flow. The keys and time interval serve to uniquely
identify the Flow. When spatially aggregating Flows, these Flows
bring their time intervals along with them. The time intervals of
the spatially aggregated Flows must either be combined through
union, or externally imposed by splitting the original Flow across
one or more intervals.</t>
<t>To address this subtle interdependency, it is more useful to
view an Aggregation Function as neither strictly temporal nor
spatial, but in terms of the types of properties affected. This
leads to the model presented in this section.</t>
</section>
<figure title="Old model of aggregation operations" anchor="iap-arch-diagram-old"><artwork><![CDATA[
original Flows
|||
||| +--------------------------+
||+ ->| interval distribution |
|| | (temporal) |---+
|| +--------------------------+ |
|| partially aggregated ^ ^ |
|| Flows | | | +-------------+
|| +-------------------+ | | +- ->| |
|| | key aggregation |<-+ | | aggregate |
|+- ->| (spatial) |------------ ->| combination |
| | |<-+ | | |
| +-------------------+ | | +- ->| |
| partially aggregated | | | +-------------+
| Flows V V | |
| +--------------------------+ | |
| | value aggregation |---+
+-- ->| (spatial) |
+--------------------------+
]]></artwork></figure>
</section> -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:43:59 |