[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                        F. Dressler
Internet-Draft                                                 C. Sommer
Expires: January 21, 2006                         University of Erlangen
                                                                 G. Munz
                                                  University of Tubingen
                                                           July 20, 2005


                           IPFIX Aggregation
               <draft-dressler-ipfix-aggregation-01.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IPFIX Aggregation describes a methodology for reducing the amount of
   measurement data exchanged between monitoring devices (IPFIX
   exporters) and analyzers (IPFIX collectors).  Using aggregation
   techniques, measurement information of multiple similar flows is
   aggregated into one meta-flow record.  The degree of similarity can
   be customized using aggregation rules.



Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 1]


Internet-Draft              IPFIX Aggregation                  July 2005


   To ensure efficient communication of both aggregated flows and the
   aggregation rules used the IPFIX Protocol and IPFIX Information Model
   are slightly extended to allow two new abstract data types and a new
   type of template set.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Aggregation Techniques . . . . . . . . . . . . . . . . . . . .  3
     2.1   Architecture . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2   Methodology  . . . . . . . . . . . . . . . . . . . . . . .  4
       2.2.1   Meta-Flows and Meta-Flow Records . . . . . . . . . . .  4
       2.2.2   Aggregation Rules  . . . . . . . . . . . . . . . . . .  5
       2.2.3   Rule Semantics . . . . . . . . . . . . . . . . . . . .  7
       2.2.4   Special Fields . . . . . . . . . . . . . . . . . . . .  7
       2.2.5   Shared Properties  . . . . . . . . . . . . . . . . . .  8
       2.2.6   Example Rule . . . . . . . . . . . . . . . . . . . . .  8
     2.3   Application Examples . . . . . . . . . . . . . . . . . . .  9
       2.3.1   Charging . . . . . . . . . . . . . . . . . . . . . . .  9
       2.3.2   Intrusion Detection  . . . . . . . . . . . . . . . . .  9

   3.  IPFIX Extensions . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1   ipv4Network  . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2   portRanges . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3   Data Template  . . . . . . . . . . . . . . . . . . . . . . 11
     3.4   Example  . . . . . . . . . . . . . . . . . . . . . . . . . 14

   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 16

   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.1   Normative References . . . . . . . . . . . . . . . . . . . 16
     5.2   Informative References . . . . . . . . . . . . . . . . . . 16

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17

       Intellectual Property and Copyright Statements . . . . . . . . 18














Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 2]


Internet-Draft              IPFIX Aggregation                  July 2005


1.  Introduction

   Flow measurement in high-speed large-scale networks easily produces a
   huge amount of data that can not be handled by a central analyzer
   without having been preprocessed.  Flow aggregators alleviate this
   problem by selectively discarding measurement information and merging
   multiple individual flows into a smaller number of meta-flows, thus
   reducing both the number of exported flow records and the amount of
   data carried by each record.  This document proposes how to design
   and implement IPFIX aggregators and introduces appropriate extensions
   to the IPFIX Protocol.

   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 [RFC2119].

2.  Aggregation Techniques

2.1  Architecture

   Aggregation of measurement data may take place at two possible
   stages:

   An internal aggregator, as depicted in Figure 1, is implemented as a
   process running in an IPFIX enabled device.  It aggregates raw data
   generated by multiple metering processes and exports them as meta-
   flow records.

   An external aggregator, called concentrator in IPFIX terminology, may
   be used where the deployed monitoring devices cannot be modified to
   incorporate an internal aggregator.  Furthermore, concentrators
   enable cascaded, multi-level aggregation of flow information.  As
   shown in Figure 2, a concentrator receives flow records from
   monitoring devices and/or lower-level concentrators and exports the
   aggregated meta-flow information to higher-level concentrators and/or
   analyzers.















Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 3]


Internet-Draft              IPFIX Aggregation                  July 2005


   +------------------------------------------+     +--------------+
   | IPFIX-enabled device       .---.   .---. |     |              |
   | .--------------------.     | A |   |   | | .-->|   Analyzer   |
   | | Metering Process 1 |-.   | g |   | E | | |   |              |
   | `--------------------' |   | g |   | x | | |   +--------------+
   |                        |   | r |   | p |---'
   |           .            '-->| e |   | o | |
   |           .                | g |-->| r | |
   |           .            .-->| a |   | t |---.
   |                        |   | t |   | e | | |   +--------------+
   | .--------------------. |   | o |   | r | | |   |              |
   | | Metering Process N |-'   | r |   |   | | '-->| Concentrator |
   | `--------------------'     `---'   `---' |     |              |
   +------------------------------------------+     +--------------+

                      Figure 1: Internal Aggregation


   +--------------+    +-----------------------+     +--------------+
   |              |    | Concentrator          |     |              |
   | Concentrator |-.  | .---.   .---.   .---. | .-->|   Analyzer   |
   |              | |  | | C |   | A |   |   | | |   |              |
   +--------------+ |  | | o |   | g |   | E | | |   +--------------+
                    '--->| l |   | g |   | x |---'
                       | | l |   | r |   | p | |
                       | | e |-->| e |-->| o | |
                       | | c |   | g |   | r | |
                    .--->| t |   | a |   | t |---.
   +--------------+ |  | | o |   | t |   | e | | |   +--------------+
   |              | |  | | r |   | o |   | r | | |   |              |
   | IPFIX device |-'  | |   |   | r |   |   | | '-->| Concentrator |
   |              |    | `---'   `---'   `---' |     |              |
   +--------------+    +-----------------------+     +--------------+

                      Figure 2: External Aggregation


2.2  Methodology

2.2.1  Meta-Flows and Meta-Flow Records

   We define the term meta-flow as an aggregate of individual flows that
   share a set of common properties.  As an example, flows directed to
   the same destination address can be aggregated into a single meta-
   flow.  Each resulting meta-flow record MAY contain a single counter
   for all packets directed to a given destination within a given time
   interval.  All flow properties that distinguish the aggregated flows
   (e.g. the source address) will not be contained in the meta-flow



Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 4]


Internet-Draft              IPFIX Aggregation                  July 2005


   record any more.  The content of the meta-flow record as well as an
   optional set of common properties for all aggregated flows is defined
   using an aggregation rule.  A Data Template, as proposed in
   Section 3.3, MAY be used to define the structure of the meta-flow
   record and to inform the analyzer about the applied aggregation rule
   and the common properties.

2.2.2  Aggregation Rules

   Regarding aggregation methodologies, a simple, rule-based approach is
   proposed.  The aggregator is supplied a list of user-defined
   aggregation rules.  An aggregation rule consists of multiple
   aggregation instructions, one for each IPFIX fields that is to be
   considered by the aggregator.  An aggregation instruction comprises
   the following elements:
   o  The IPFIX field the aggregation instruction refers to (e.g.
      destinationIPv4Address).  Only flows that contain the field
      mentioned will be considered for aggregation in the meta-flow.
   o  An optional pattern for this field that restricts the aggregation
      to those flows that match the given value(s) (e.g. 10.10.0.0/16).
      Only flows that match all patterns of the rule will be aggregated
      in the meta-flow.
   o  One of the field modifiers "discard", "keep", "aggregate", or
      "mask" that specifies how this field is treated by the aggregator
      and if it is included in the meta-flow record or not.

   With this definition of aggregation instructions each rule also
   unambiguosly defines the content of the meta-flow record as well as
   the template to export the meta-flow information.  If and how a field
   is present in the meta-flow record, depends on the field modifier and
   is explained below.  Fields that do not appear in any of the
   aggregation instructions, are not part of the meta-flow record.
   Since the export of a meta-flow record requires an appropriate
   template, a one-to-one relationship between rules and templates can
   be established.

   The following field modifiers are applicable to Flow Keys as defined
   in [I-D.ietf-ipfix-architecture].
   discard:
      The field is not included in the meta-flow records, i.e. meta-
      flows are not distinguishable with respect to this field.
      Incoming flow records with different values for this IPFIX field
      are merged.








Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 5]


Internet-Draft              IPFIX Aggregation                  July 2005


   keep:
      The field is included in the meta-flow record, i.e. meta-flows are
      distinguishable with respect to this field.  Incoming flow records
      with different values for this field are not merged, but
      contribute to different meta-flows instead.

   mask/n:
      (Applicable to IP addresses only) The field is included in the
      meta-flow record, but the number of significant bits reduced to n
      bits.  Incoming flow records with IP addresses belonging to the
      same subnet are merged, so meta-flows are distinguishable with
      respect to resulting subnet addresses only.  In accordance with
      the IPFIX Information Model the resulting IP address is
      transferred as one IP prefix field and one IP mask field.


   If an aggregation instruction refers to one of the field types
   mentioned in Section 2.2.4, no pattern must be specified.  The only
   possible field modifier is:
   aggregate:
      The field is included in the meta-flow record.  The determination
      of the value depends on the field type and is specified in
      Section 2.2.4.  As an example, a counter field in a meta-flow
      record is assigned the sum of the corresponding values in the
      incoming flow records.


   Using the Data Template proposed in Section 3.3, the receiving
   collector is informed about the current rule set.  Table 1 summarizes
   the field modifiers and the resulting information in the meta-flow
   records and Data Templates, respectively.

   +----------------+----------------+----------------+----------------+
   | field modifier | pattern        | field in       | fixed-value    |
   |                |                | meta-flow      | field in Data  |
   |                |                | record         | Template       |
   +----------------+----------------+----------------+----------------+
   | discard        | no             | N/A            | N/A            |
   | discard        | yes            | N/A            | yes, contains  |
   |                |                |                | pattern        |
   | keep           | no             | yes            | N/A            |
   | keep           | yes            | yes, if        | yes, contains  |
   |                |                | pattern        | pattern        |
   |                |                | specifies a    |                |
   |                |                | range of       |                |
   |                |                | values         |                |





Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 6]


Internet-Draft              IPFIX Aggregation                  July 2005


   | mask           | no             | yes, IP        | N/A            |
   |                |                | network        |                |
   |                |                | address        |                |
   | mask           | yes            | yes, IP        | yes, contains  |
   |                |                | network        | pattern        |
   |                |                | address        |                |
   +----------------+----------------+----------------+----------------+

     Table 1: Relation between field modifiers, meta-flow records, and
                              Data Templates


2.2.3  Rule Semantics

   By default, incoming flow records are checked against every
   aggregation rule.  If a rule matches, i.e. if the flow record
   comprises all required fields and matches all given patterns, the
   field modifiers are applied and the corresponding meta-flow record is
   generated or updated.  Incoming flow records that match multiple
   rules thus contribute to multiple meta-flows.

   In some cases, it is prefered that an incoming flow record that
   matched a certain rule is not checked against other rules in order to
   avoid that this flow contributes to multiple meta-flows.  Therefore,
   it is possible to indicate a preceding rule for each aggregation rule
   that has to be check before.  The current rule is not applied if the
   flow record already matched the preceding rule.  Using the preceding
   rule relationship, rules can be organized in rule chains and rule
   trees where only the first matching rule is applied in every chain or
   branch.  Rules that do not define a preceding rule are checked
   against all incoming flow records and constitute the beginning of a
   rule chain or the root of a rule tree.  Consequently, each flow
   record is counted only once within a single chain or branch, or not
   at all if none of the rules matches.

   The Preceding Rule field in the header of the Data Template (see
   Section 3.3) is used to identify the preceding rule by its Template
   ID.  If set to 0, there is no preceding rule and the rule is checked
   against all incoming records.

2.2.4  Special Fields

   Fields that do not carry information about Flow Keys (see [I-D.ietf-
   ipfix-architecture]) but metering information, such as counters,
   timestamps etc., require special treatment.  For example, the meta-
   flow's start timestamp is set to the minimum of the comprising flows'
   start timestamps.  Packet and byte counters of aggregated flows are
   summed up.



Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 7]


Internet-Draft              IPFIX Aggregation                  July 2005


   Table 2 contains an overview of such fields for which a special
   treatment is proposed.  Refer to the IPFIX Information Model
   [I-D.ietf-ipfix-info] for a description of the fields mentioned.

                 +-----------------------+-----------+
                 | Field                 | Set To    |
                 +-----------------------+-----------+
                 | minimumPacketLength   | minimum   |
                 | minimumTtl            | minimum   |
                 | flowStartSeconds      | minimum   |
                 | flowStartMilliSeconds | minimum   |
                 | maximumPacketLength   | maximum   |
                 | maximumTtl            | maximum   |
                 | flowEndSeconds        | maximum   |
                 | flowEndMilliSeconds   | maximum   |
                 | ipv6OptionHeaders     | binary OR |
                 | tcpControlBits        | binary OR |
                 | octetDeltaCount       | sum       |
                 | packetDeltaCount      | sum       |
                 +-----------------------+-----------+

           Table 2: Information with Implicit Aggregation Rules


2.2.5  Shared Properties

   Matching patterns of fields (e.g. source port 80 and destination
   network 10.10.0.0/16 in the previous example) constitute shared
   properties of exported flows.  Such shared properties are equal for
   all meta-flows resulting from the corresponding aggregation rule.
   Shared properties MAY be exported as regular IPFIX fields.  However,
   in order to reduce redundancy and to make patterns distinguishable
   from other fields, they SHOULD be transmitted as fixed-value fields
   using the Data Template proposed in Section 3.3.  As a result, no
   separate transmission of the aggregation instructions needs take
   place.

2.2.6  Example Rule

   Here is an example rule with four aggregation instructions:
   1.  Aggregate
       *  discard sourceTransportPort in 80
       *  keep sourceIPv4Address
       *  mask/24 destinationIPv4Address in 10.10.0.0/16
       *  aggregate packetDeltaCount

   This rule aggregates all flows to a destination address in the subnet
   10.10.0.0/16 with source port equal to 80.  Destination addresses are



Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 8]


Internet-Draft              IPFIX Aggregation                  July 2005


   merged according to subnets in 10.10.x.0/24.  The resulting meta-flow
   records comprise the source address, the destination subnet address,
   and the packet counter.

2.3  Application Examples

2.3.1  Charging

   Monitoring and accouting for charging applications require saving
   information about each individual end system.  Further information
   about each particular flow is not required.  Therefore, aggregation
   rules are appropriate if the address of the end system is retained.

   An example ruleset might consist of the following instructions:
   1.  Aggregate
       *  keep destinationIPv4Address in 10.10.0.0/16
       *  aggregate packetDeltaCount
   2.  Aggregate
       *  keep sourceIPv4Address in 10.10.0.0/16
       *  aggregate packetDeltaCount

   Thus, aggregated meta-flows will be created for all inbound and
   outbound traffic of the network managed, separated by direction and
   host.  Protocol and port information will be discarded.

2.3.2  Intrusion Detection

   If monitoring is employed for further analysis in terms of intrusion
   detection, i.e. anomaly detection, rule-based intrusion detection,
   etc., information about used protocols at transport layer as well as
   at application layer is mostly required.  On the other hand, the
   analysis will typically work on the basis of subnetworks instead of
   single hosts because the analysis of individual flows would require
   to much processing power.  Accurate information about the traffic
   between individual end systems is only required if suspicious
   transmissions have already been detected.

   An example ruleset might consist of the following instructions:
   1.  Aggregate
       *  keep destinationIPv4Address in 10.10.0.0/16
       *  mask/24 sourceIPv4Address
       *  keep protocolIdentifier
       *  keep destinationTransportPort
       *  aggregate packetDeltaCount

   Thus, aggregated meta-flows will be created for all packets to hosts
   in a particular network.  The destination port and the protocol will
   be preserved and the source port will be discarded.



Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt     [Page 9]


Internet-Draft              IPFIX Aggregation                  July 2005


3.  IPFIX Extensions

   After having a rule's field modifiers applied, all data records that
   matched a rule comprise the same fields, so for each rule exactly one
   template can be used.  In order to efficiently transmit aggregated
   flows, however, three extensions to IPFIX are required:
   o  New abstract data type "IPNetwork"
   o  New abstract data type "portRanges"
   o  New "Data Template" set

3.1  ipv4Network

   Currently, the transport of IP network information as specified by
   IPFIX is done using separate fields for the network address and the
   corresponding mask.  We propose a new abstract data type ipv4Network
   that represents the common notation of IP networks: address/mask.
   Thus, this data type is build of an unsigned32 for the IPv4 address
   and a single byte for the prefix length, whereas the encoding of the
   IPv4 address corresponds to the definition of the ipv4Address in the
   IPFIX Information Model.

   ipv4Network is required because it offers more flexibility and
   scalability if hugh numbers of IPv4 networks have to be transmitted,
   as ususally done using IPFIX Aggregation.

3.2  portRanges

   As the current draft contains no data type to transmit port lists or
   port ranges, but many applications require port-based aggregation,
   this section defines a new abstract data type for a list of port
   ranges.

   portRanges is a finite length string of unsigned32 values, each
   consisting of an unsigned16 start port followed by an unsigned16 end
   port specification.
   portRanges MAY be used as a variable-length data type as defined in
   [I-D.ietf-ipfix-protocol].
   Data types basing on portRanges MAY also be cast down to unsigned16
   to represent a single Port.  Hence, the transportSourcePort and
   transportDestinationPort data types, currently based on the
   unsigned16 abstract data type, MAY be replaced by portRanges.










Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 10]


Internet-Draft              IPFIX Aggregation                  July 2005


      +---------------+--------+---------------------------------+
      | Ports         | Length | Hexadecimal Representation      |
      +---------------+--------+---------------------------------+
      | 80            | 2      | 0050                            |
      | 1:7           | 4      | 0001 0007                       |
      | 80, 443       | 8      | 0050 0050 01BB 01BB             |
      | 1:7, 256:1024 | 8      | 0001 0007 0100 0400             |
      | 20, 80, 443   | 12     | 0014 0014 0050 0050 01BB 01BB   |
      | 1:7, 80, 443  | 12     | 0001 0007 0050 0050 01BB 01BB   |
      +---------------+--------+---------------------------------+

                       Table 3: PortRanges Examples


3.3  Data Template

   When doing rule based aggregation of flows, the resulting meta-flows
   share many field values.  In order to avoid the overhead of the
   repeated transmission of these shared properties in all meta-flow
   records resulting from a given rule, a new template type is
   introduced.  Additionally, the aggregation rule set is provided to
   the analyzer.  Using this information, the collector is able to
   quantify the received data.

   This template type, termed a "Data Template", allows the sender to
   both declare and define common properties of Data Sets based on it.
   The basic format of a Data Template Set is the same as that of a
   Template Set and - for the sake of completeness - is shown in
   Figure 3.  The format of individual template definitions, however,
   differs from that of the standard Template and is shown in Figure 4.





















Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 11]


Internet-Draft              IPFIX Aggregation                  July 2005


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 4           |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Data Template 1                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Data Template N                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Padding (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3: Data Template Set Format

   The Data Template Set field definitions are as follows:
   Set ID
      Type of this template set.  A set ID value of 4 is proposed for
      the Data Template Set.

   Length
      Total length of this set in bytes.

   Padding
      Optional padding to fill the set to a word boundary.  It MUST
      consist of null-bytes and be at most seven bytes in length


















Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 12]


Internet-Draft              IPFIX Aggregation                  July 2005


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Template ID                  |  Field Count                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data Count                   |  Preceding Rule               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Field 1 Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Field N Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data 1 Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data M Type                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data 1 Value                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                              ...                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Data M Value                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 4: Data Template Format

   The Data Template field definitions are as follows:




Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 13]


Internet-Draft              IPFIX Aggregation                  July 2005


   Template ID
      See the description of a Type 3 Template Set in [I-D.ietf-ipfix-
      protocol]

   Field Count
      Number of regular Fields that will be sent in subsequent Data Sets
      using this Template.

   Data Count
      Number of fixed-value Fields that will be sent in this Template.

   Preceding Rule
      Template ID of the preceding rule that is checked before, or 0 if
      all incoming records are checked against this rule.  When
      organizing aggregation rules in a chain or tree where rules are
      sequentially checked on a first-match basis as proposed in
      Section 2.2.3, the order in which rules are checked needs to be
      made clear to the receiving collector.  Because of the one-to-one
      mapping between rules and template IDs, communicating the order of
      rules is as simple as embedding the preceding rule's Template ID
      into the Data Template(s) of the rule(s) that follow(s).  This way
      the concentrator is implicitly sent the order of the aggregation
      rules within the chain or tree.

   Field N Type
      Type identifier, Type length and an enterprise number (if needed)
      of field N. Refer to [I-D.ietf-ipfix-protocol] for more
      information on Field Types

   Data M Type
      Same as "Field N Type", but used for common properties of all Data
      Sets that use this Template.  Together with Data M Value, a
      similar encoding like TLV is achieved.

   Data M Value
      Bit representation of a common property as would be transmitted in
      a Data Set.


3.4  Example

   In this example we assume the concentrator was given the following
   aggregation rule:
   1.  Aggregate
       *  discard sourceIPv4Address in 10.0.0.0/23
       *  keep destinatonTransportPort





Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 14]


Internet-Draft              IPFIX Aggregation                  July 2005


       *  aggregate packetDeltaCount

   We further assume the concentrator receives the following flow
   records:

   +------------+------------+-------------+-------------+-------------+
   | Source IP  | Source     | Destination | Destination | Packets     |
   |            | Port       | IP          | Port        |             |
   +------------+------------+-------------+-------------+-------------+
   | 10.0.0.1   | 64235      | 10.0.0.10   | 80          | 10          |
   | 10.0.1.2   | 64236      | 10.0.0.11   | 110         | 10          |
   | 10.0.0.3   | 64237      | 10.0.0.12   | 80          | 10          |
   | 10.0.2.4   | 64238      | 10.0.0.13   | 80          | 10          |
   | 10.0.2.5   | 64239      | 10.0.0.14   | 80          | 10          |
   +------------+------------+-------------+-------------+-------------+

                          Table 4: Incoming Flows

   Based on the aggregation rule stated above the concentrator would now
   first send a Data Template Set containing the Data Template
   corresponding to the given rule:

                  +--------------+-------------------+
                  | Field        | Value             |
                  +--------------+-------------------+
                  | Template ID  | 10001             |
                  | Field Count  | 2                 |
                  | Data Count   | 2                 |
                  | Reserved     | 0                 |
                  | Field 1 Type | Destination Port  |
                  | Field 2 Type | Packets           |
                  | Data 1 Type  | Source IP Network |
                  | Data 2 Type  | Source IP Mask    |
                  | Data 1 Value | 10.10.0.0         |
                  | Data 2 Value | 23                |
                  +--------------+-------------------+

                        Table 5: Data Template used













Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 15]


Internet-Draft              IPFIX Aggregation                  July 2005


   The second Set transmitted now uses this Data Template to send all
   flows that matched the given rule.  Note that the flows' common
   property, a Source IP of 10.0.0.0/23, was already transmitted in the
   template, so besides the packet count only the flows' discriminating
   property, their destination port, is sent in the data records:

                     +------------------+---------+
                     | Destination Port | Packets |
                     +------------------+---------+
                     | 80               | 20      |
                     | 110              | 10      |
                     +------------------+---------+

                         Table 6: Aggregated Flows


4.  Security considerations

   As all methods described in this document are merely variations on
   methods already introduced in [I-D.ietf-ipfix-protocol], the same
   rules regarding exchange of flow information apply.

5.  References

5.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

5.2  Informative References

   [I-D.ietf-ipfix-architecture]
              Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export",
              draft-ietf-ipfix-architecture-08 (work in progress),
              March 2005.

   [I-D.ietf-ipfix-protocol]
              Claise, B., "IPFIX Protocol Specifications",
              draft-ietf-ipfix-protocol-16 (work in progress),
              June 2005.

   [I-D.ietf-ipfix-info]
              Quittek, J., Bryant, S., Claise, B., and J. Meyer,
              "Information Model for IP Flow Information Export",
              draft-ietf-ipfix-info-07 (work in progress), May 2005.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,



Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 16]


Internet-Draft              IPFIX Aggregation                  July 2005


              "Requirements for IP Flow Information Export", RFC 3917,
              October 2004.


Authors' Addresses

   Falko Dressler
   University of Erlangen
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058
   Germany

   Phone: +49 9131 85-27914
   Email: dressler@informatik.uni-erlangen.de
   URI:   http://www7.informatik.uni-erlangen.de/


   Christoph Sommer
   University of Erlangen
   Department of Computer Science 7
   Martensstr. 3
   Erlangen  91058
   Germany

   Email: sichsomm@stud.informatik.uni-erlangen.de


   Gerhard Munz
   University of Tubingen
   Computer Networks and Internet
   Auf der Morgenstelle 10C
   Tubingen  72076
   Germany

   Phone: +49 7071 29-70534
   Email: muenz@informatik.uni-tuebingen.de
   URI:   http://net.informatik.uni-tuebingen.de/













Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 17]


Internet-Draft              IPFIX Aggregation                  July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Dressler, et al.    draft-dressler-ipfix-aggregation-01.txt    [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/