Network Working Group F. Dressler Internet-Draft C. Sommer Expires: July 31, 2005 University of Erlangen G. Muenz University of Tuebingen January 27, 2005 IPFIX Aggregation Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 July 31, 2005. 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 similar flows is aggregated Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 1] Internet-Draft IPFIX Aggregation January 2005 into one metaflow. The degree of similarity can be defined using aggregation rules. To achieve further reduction of the amount of data exchanged while still transmitting all required information to the collector, the IPFIX protocol and Information Model is slightly extended to allow two new data types and a new template / template set. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Aggregation Techniques . . . . . . . . . . . . . . . . . . . . 3 2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Explicit Rules . . . . . . . . . . . . . . . . . . . . 4 2.2.2 Special Fields . . . . . . . . . . . . . . . . . . . . 6 2.2.3 Shared Properties . . . . . . . . . . . . . . . . . . 6 2.3 Application Examples . . . . . . . . . . . . . . . . . . . 7 2.3.1 Charging . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2 Intrusion Detection . . . . . . . . . . . . . . . . . 7 3. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 PrecedingRule . . . . . . . . . . . . . . . . . . . . . . 8 3.2 PortRanges . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Data Template . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Security considerations . . . . . . . . . . . . . . . . . . . 13 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 2] Internet-Draft IPFIX Aggregation January 2005 1. Introduction Flow measurement in high speed, large scale networks can quickly produce an amount of data that can no longer be handled by a central monitoring station without having been preprocessed. Flow aggregators try to alleviate this problem by selectively discarding data and merging flows into bigger metaflows, thus reducing both the number of flows sent and the amount of data carried in each flow record. This document proposes ways of designing and implementing IPFIX aggregators and introduces extensions to IPFIX necessary for doing so. 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 (see Figure 1) might be implemented as a process running in an IPFIX enabled device, aggregating raw data collected by multiple metering processes and exporting it as metaflows. An external aggregator, as shown in Figure 2, might be appropiate where the collecting device cannot be refitted with an aggregator or if cascaded aggreagtion is desired. External aggregators, called concentrators in IPFIX terminology, receive flows from lower-level concentrators or measurement devices' exporters and export the aggregated metaflows to a higher-level concentrator or a monitoring station. Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 3] Internet-Draft IPFIX Aggregation January 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 Procedure 2.2.1 Explicit Rules Regarding methods of aggregation, a simple, rule-based approach is proposed: The concentrator is supplied a list of user-defined rules. Each rule consists of multiple aggregation instructions describing o The type of IPFIX field the aggregation instruction refers to (e.g. "Destination IP") Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 4] Internet-Draft IPFIX Aggregation January 2005 o A matching pattern (e.g. 10.10.0.0/16). In order for an incoming IPFIX record to be aggregated according to a given rule, all of its aggregation instruction's patterns need to be matched by the incoming record's corresponding fields' values. o A granularity modifier (e.g. "keep field"). If the aggregation instruction refers to a regular field type, the modifier can either be "discard field" or "keep field". If the aggregation instruction refers to a field of type "IP address", the modifier can also only selectively discard bits of the IP address by applying a network mask. If the aggregation instruction refers to one of the special field types mentioned in Section 2.2.2 the modifier takes a fixed value of "aggregate" and the aggregation instruction acts according to Section 2.2.2. This way each rule also unambiguosly defines o A minimal set of IPFIX fields an incoming record needs to transport to potentially match this rule: All fields mentioned in the rule's aggregation instructions MUST be present. o The template used when exporting flows matching this rule: Each field mentioned in the rule's aggregation instructions that does not have its granularity modifier set to "discard" will be present in all flows that were aggregated according to this rule. Other fields of an incoming flow that have no matching aggregation instruction are neither considered nor exported. Regarding treatment of incoming flow records that matched a given rule, two possible implementations can be thought of: First-match An incoming flow record is sequentially checked against each rule. If all fields of the flow record match the corresponding fields of the aggregation rule, the rule's granularity modifiers are applied and the flow is aggregated. No further processing of this flow takes place. Because in this case a receiver of aggregated flows needs to be aware of the order in which rules were checked, exported flows carry an additional field that points to flows matching a preceding rule. See Section 3.1 for a possible implementation. Each possible match An alternative implementation might check each incoming record against every rule. If all fields of the flow record match the corresponding fields of an aggregation rule, a copy of the flow has the rule's granularity modifiers applied, is aggregated and processing of the original flow continues with the next rule. In this case the order of rules need not be transmitted. Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 5] Internet-Draft IPFIX Aggregation January 2005 2.2.2 Special Fields Fields that describe properties of the flow itself rather than properties of packets that made up the flow receive special treatment: A flow's begin-timestamp is set to the minimum of the comprising flows' timestamps, Packet and byte counters of aggregated flows are summed up, etc. All fields (see also the IPFIX information model [I-D.ietf-ipfix-info]) that require special processing are summarized in Table 1. +--------------------------------+---------------------------------+ | Field | Action | +--------------------------------+---------------------------------+ | # packets | sum of all aggregated flows | | # bytes | sum of all aggregated flows | | # flows | sum of all aggregated flows | | timestamp of first seen packet | minimum of all aggregated flows | | timestamp of last seen packet | maximum of all aggreagted flows | +--------------------------------+---------------------------------+ Table 1: Information with Implicit Aggregation Rules 2.2.3 Shared Properties Matching patterns of fields (e.g., an IP address matching a subnetwork) constitute shared properties of exported flows. Such shared properties are equal for each flow and , therefore, MAY be exported as regular IPFIX fields. They SHOULD, however, be transmitted as shared properties using the Data Template proposed in Section 3.3. No separate transmissions of aggregation instructions need take place. Let us consider an example ruleset: 1. Match Source Port 80. Match Destination IPs in 10.10.0.0/16, apply mask /24. Aggregate # packets. 2. Aggregate # packets. The first rule aggregates all flows to a destination in 10.10.x.0/24 with source port equal to 80. The shared properties of all these flows are the source port (80) and the destination address (one in 10.10.x.0). Thus, this ruleset provides quick packet counters for outbound HTTP traffic in subnets 10.10.x.0, providing an additional packet counter for all other flows. Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 6] Internet-Draft IPFIX Aggregation January 2005 2.3 Application Examples 2.3.1 Charging Monitoring and accouting for charging applications requires to save 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. Match Destination IP in 10.10.0.0/16, keep field. Aggregate # packets. 2. Match Source IP in 10.10.0.0/16, keep field. Aggregate # packets. 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 are mostly required. On the other hand, the analysis will typically work on the basis of subnetworks instead of single hosts because of the amount of data to process. Information about the traffic between individual end systems is required if suspicious transmissions were alread detected. An example ruleset might consist of the following instructions: 1. Match Destination IP in 10.10.0.0/16, keep field Match any Source IP, mask /24 Match any Protocol, keep field Match any Destination Port, keep field Aggregate # packets. Thus, aggregated meta flows will be created for all packets to hosts in particular networks. The destination port and the protocol will be preserved and the source port will be discarded. 3. Data Export After having a rule's granularity 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: Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 7] Internet-Draft IPFIX Aggregation January 2005 o data type: PrecedingRule o data type: PortRanges o template / template set: Data Template 3.1 PrecedingRule When doing rule-based aggregation and creating metaflows on a first-match basis, like proposed in Section 2.2, the order in which rules are checked needs to be made clear to the receiver. 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 exported metaflows. A new data type, PrecedingRule, which is based on the unsigned16 abstract data type and can be embedded into a DataTemplate as presented in Section 3.3, serves exactly this purpose. This way the concentrator is implicitely sent aggregation rules or, at least, the actually used aggregation rules and their order. 3.2 PortRanges As the current draft contains no data type to transmit port lists or port ranges, 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. Therefore, 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-00.txt [Page 8] Internet-Draft IPFIX Aggregation January 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 2: PortRanges Examples 3.3 Data Template When doing rule based aggregation of flows, the resulting metaflows share many field values. In order to avoid the overhead of repeatedly transmitting these common values of all flows that matched a given rule, a new template type is introduced. 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-00.txt [Page 9] Internet-Draft IPFIX Aggregation January 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. MUST consist of null-bytes and be at most seven bytes in length 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field 1 Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 10] Internet-Draft IPFIX Aggregation January 2005 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 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: 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. Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 11] Internet-Draft IPFIX Aggregation January 2005 Reserved Reserved, MUST be 0. 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 rules: 1. Match source IPs in 10.0.0.0/23, discard field. Match any destination port, keep field. Aggregate # packets. 2. Pass through all other flows 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 3: Incoming Flows Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 12] Internet-Draft IPFIX Aggregation January 2005 Given the example rules and flows from above, the concentrator would now use one Template to send all flows that matched no given rule and were thus not aggregatable: +------------+------------+-------------+-------------+-------------+ | Source IP | Source | Destination | Destination | Packets | | | Port | IP | Port | | +------------+------------+-------------+-------------+-------------+ | 10.0.2.4 | 64238 | 10.0.0.13 | 80 | 10 | | 10.0.2.5 | 64239 | 10.0.0.14 | 80 | 10 | +------------+------------+-------------+-------------+-------------+ Table 4: Outgoing Flows I The second Data Set uses a Data Template to send all flows that matched our aggregation 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 5: Outgoing Flows II 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-protocol] Claise, B., "IPFIX Protocol Specifications", Internet-Draft draft-ietf-ipfix-protocol-07, December Dressler, et al. draft-dressler-ipfix-aggregation-00.txt [Page 13] Internet-Draft IPFIX Aggregation January 2005 2004. [I-D.ietf-ipfix-info] Meyer, J., Quittek, J. and S. Bryant, "Information Model for IP Flow Information Export", Internet-Draft draft-ietf-ipfix-info-05, October 2004. [RFC3917] Quittek, J., Zseby, T., Claise, B. and S. Zander, "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 Muenz University of Tuebingen Computer Networks and Internet Auf der Morgenstelle 10C Tuebingen 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-00.txt [Page 14] Internet-Draft IPFIX Aggregation January 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-00.txt [Page 15]