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 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]