Network Working Group F. Dressler Internet-Draft C. Sommer Intended status: Standards Track Univ. Erlangen Expires: January 15, 2009 G. Muenz Univ. Tuebingen A. Kobayashi NTT PF Lab. July 14, 2008 IPFIX Flow 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 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract IPFIX Flow Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX Exporters) and analyzers (IPFIX Collectors). Aggregation techniques represent a necessary enhancement in order to cope with Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 1] Internet-Draft IPFIX Flow Aggregation July 2008 increasing amounts of monitoring data that accrue with the ever- growing network capacities. Using Flow Selection Criteria and Compound Flow creation techniques, measurement information of multiple Flows that are sharing some common criteria is merged to be exported in one Compound Flow. Subsets of Flows eligible for aggregation, as well as the desired degree of similarity, can be customized using a set of Aggregation Rules. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Compound Flow Creation . . . . . . . . . . . . . . . . . . . . 5 6. Aggregation Rules . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Single Aggregation Rule . . . . . . . . . . . . . . . . . 7 6.2. Multiple Aggregation Rules . . . . . . . . . . . . . . . . 8 6.3. Deriving Templates from Aggregation Rules . . . . . . . . 8 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 2] Internet-Draft IPFIX Flow Aggregation July 2008 1. Introduction Flow measurement in high-speed large-scale networks easily produces an amount of data that can no longer be handled by a single IPFIX Collector. Also, many applications processing Flow measurement data do not require detailed Flow-level information, but require only generic Flow information, with the scope of this information being very application-specific. Examples for applications benefiting of IPFIX Flow aggregation are charging and intrusion detection. In the former application, detailed information about individual Flows is not required. Similarly, intrusion detection applications may be satisfied with Flow information for specific subnets. Flow aggregation is also a viable solution for the anonymization of Flow information. This document presents a flexible Flow aggregation scheme that helps reduce the number and the size of exported Flow Records, as well as helps adapt the transmitted measurement information to the requirements of deployed applications. Measurement data reduction is achieved by discarding unneeded measurement information and merging multiple individual Flows into a smaller number of Compound Flows, which are then exported to the analyzer. Flow aggregation will usually take place in an IPFIX concentrator. Monitoring networks can thus be deployed in a logical tree topology, using multiple levels of intermediate concentrators, rather than in a logical star topology. The following sections illustrate the design and implementation of Flow aggregation. 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. Terminology Apart from the basic terms described in [RFC3917], [RFC5101], and [I-D.ietf-ipfix-architecture], the following terms are used within this document: Compound Flow: A Compound Flow is the result of an aggregation of one or more individual input Flows that matched an Aggregation Rule. It might, for example, contain the total count of all packets addressed to a common subnet that were observed within a given time interval. Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 3] Internet-Draft IPFIX Flow Aggregation July 2008 Aggregation Rule: An Aggregation Rule defines the properties of a Compound Flow and the contents of the corresponding Flow Records. Optionally, a set of selection criteria MAY be specified in order to restrict the applicability of the Aggregation Rule to those Flows that show certain patterns. Preceding Rule: The Preceding Rule represents a mechanism to inform the collector about the position of the matching Aggregation Rule in the entire chain or tree of Aggregation Rules. This parameter MAY be used to dynamically transmit parts of the rule chain or tree. 3. Aggregation An IPFIX concentrator, as introduced in [RFC3917], MAY be employed to save processing resources of distributed monitoring devices by providing aggregation techniques. Aggregated Flow data is exported in form of Compound Flows. Furthermore, concentrators enable cascaded, multi-level aggregation of Flow information. In order to efficiently customize both the contents and the size of exported Compound Flows, a two-step approach is proposed. 1. Incoming Flows are selected by comparing contained information with configured Selection Criteria, enabling the aggregator to discard unwanted Flows. 2. The selected Flows are aggregated by discarding fields or parts of fields, enabling the aggregator to create Compound Flows by merging Flows according to a reduced Flow Key. These two independent steps are introduced in the next two sections. A mediation device can use either one or both. 4. Selection Depending on the configuration of the mediator, the receiver of Flows may be only interested in a subset of all Flows that matches certain patterns. Thus, patterns act as criteria that enable the selection of Flows eligible for aggregation and subsequent export to the analyzer. For example, the pattern "80" can configured for the sourceTransportPort field in order to export only Compound Flows sent by an HTTP server. Selecting Flows means that all of the source Flows that make up a Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 4] Internet-Draft IPFIX Flow Aggregation July 2008 certain Compound Flow will share a specific set of field values (e.g. destination address 192.0.2.1 and destination port 80). This common set of field values MUST be transmitted to receivers along with Compound Flows' specific field values, so as not to lose information. In order to conserve traffic volume it SHOULD, however, not be directly included in all exported Compound Flow Records, but rather communicated by more bandwidth-conserving means which still guarantee a stable association from specific properties to Common Properties of a Flow. One such means is the transmission as a set of Common Properties. This concept is introduced in [RFC5102] and illustrated in Figure 1. In order to unambiguously communicate to receivers which Common Properties of a Flow stem from aggregation, when multiple Common Properties are transmitted in one Flow, an aggregator SHOULD make sure that the first commonPropertiesID transmitted in Flows directly corresponds to the set of selection criteria used. Selection Criterion 1: +######+---------------+ # CP=1 # SRC=192.0.2.1 | +######+---------------+ Selection Criterion 2: +######+---------------+ # CP=2 # DST=192.0.2.2 | +######+---------------+ ^ '-------------------. Flow: v +--------+-----------+------+ | SPT=80 | DPT=65432 | CP=2 | +--------+-----------+------+ Figure 1: Using Common Properties to transmit Selection Criteria 5. Compound Flow Creation The second aggregation step is the creation of Compound Flows. Selected Flows can be aggregated by discarding fields or parts of fields, enabling the aggregator to create Compound Flows by merging Flows according to a reduced Flow Key. The following field modifiers can be applied: Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 5] Internet-Draft IPFIX Flow Aggregation July 2008 discard: The field is not included in Compound Flow Records, i.e. Compound Flows are not distinguishable with respect to this field. Incoming Flows with different values for this field can be merged and thus contribute to the same Compound Flow. keep: The field is included unmodified in Compound Flow Records, i.e. Compound Flows are distinguishable with respect to this field. Incoming Flows with different values for this field are not merged, but contribute to different Compound Flows instead. mask to n bits: The field is included in Compound Flow Records, but the number of significant bits is reduced (applicable to IP addresses only). Incoming Flows with IP addresses belonging to the same subnet are merged, so Compound Flows are distinguishable with respect to resulting subnet addresses only. In accordance with [RFC5102], the resulting subnet address MAY be encoded with an IP prefix field and an IP mask field. For performance reasons it SHOULD, however, be encoded with a single field of the abstract data type ipv4Network introduced in [I-D.sommer-ipfix-mediator-ext]. aggregate: The field is included in Compound Flow Records, but field values derived from multiple incoming Flows' values. The value of fields with a field modifier of "aggregate" is computed from the corresponding values of the original Flows by taking the most appropriate of the following actions (listed in ascending order of priority): 1. As also specified in [RFC5102] the value of variable fields, which may change from packet to packet within a single Flow, is determined by the first packet observed for the corresponding Compound Flow. As a consequence, if no other action is more appropriate, the default behavior requires using the value of the incoming Flow Record with the earliest start timestamp. 2. For some Information Elements, [RFC5102] explicitly specifies a different semantic, which is to then take precedence over the aforementioned default behavior. 3. For some Information Elements, Table 1 specifies an aggregation function that has to be used in order to obtain a correct, aggregated value. If such an aggregation function is listed, it takes precedence over all other available functions. For example, the start timestamp of the Compound Flow is always set Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 6] Internet-Draft IPFIX Flow Aggregation July 2008 to the minimum of the original start timestamps, while packet and octet counts of aggregated Flows are always summed up. +-----------------------+----------------------+ | Information Element | Aggregation Function | +-----------------------+----------------------+ | minimumPacketLength | min | | minimumTtl | min | | flowStartSeconds | min | | flowStartMilliSeconds | min | | maximumPacketLength | max | | maximumTtl | max | | flowEndSeconds | max | | flowEndMilliSeconds | max | | octetDeltaCount | sum | | packetDeltaCount | sum | +-----------------------+----------------------+ Table 1: Treatment of Fields Carrying Metering Information 6. Aggregation Rules For the configuration of selection and compound flow creation, a rule-based approach is proposed, where each aggregator is supplied a list of user-defined Aggregation Rules. 6.1. Single Aggregation Rule An Aggregation Rule (see Section 7 for an example) consists of multiple instructions, one for each data field that is to be considered. Each of the Aggregation Rules' instructions comprises the following elements: o The data field the instruction refers to (e.g. destinationIPv4Address). Only Flows that contain the field mentioned will be eligible for aggregation according to this Aggregation Rule. o An optional Selection Criterion (Section 4), e.g. 192.0.2.0/24, for this field that further restricts eligibility of incoming Flows to those that match the given value(s). Only Flows that match all patterns of the Aggregation Rule will be aggregated. o An optional field modifier enabling Compound Flow creation (Section 5) , e.g. mask to 28 bits, that either configures how much information in this field should be retained unmodified by the aggregator or that the field's values should be aggregated Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 7] Internet-Draft IPFIX Flow Aggregation July 2008 instead. Fields that do not appear in any of an Aggregation Rule's instructions are not part of its associated Compound Flow Records. Incoming Flows that are not covered by any Aggregation Rule are discarded. 6.2. Multiple Aggregation Rules By default, incoming Flow Records are checked against all of the configured Aggregation Rules. If an Aggregation Rule matches, i.e. if the Flow Record comprises all required fields and matches all given patterns, the field modifiers are applied and corresponding Compound Flow Records generated or updated. Therefore, incoming Flow Records that match multiple Aggregation Rules contribute to multiple Compound Flows. In some cases, it is preferred that an incoming Flow Record that matched a certain Aggregation Rule is not checked against further Aggregation Rules in order to avoid that this Flow contributes to multiple Compound Flows. Therefore, it is possible to indicate a Preceding Rule for each Aggregation Rule. If a Preceding Rule is set for an Aggregation Rule, an aggregator first tries to aggregate an incoming Flow according to the Preceding Rule. Only if the Preceding Rule is not applicable, e.g. because the incoming Flow does not match the given pattern, the current Aggregation Rule is applied. Using the Preceding Rule relationship, Aggregation Rules can thus be organized in rule chains and rule trees where only the first matching Aggregation Rule is applied in every chain or branch. Consequently, each incoming Flow Record is aggregated at most once per chain or tree. Rules that do not define a Preceding Rule constitute the beginning of a rule chain or the root of a rule tree and are used to check all incoming Flow Records. If a Preceding Rule is set for an Aggregation Rule, a suitable mechanism SHOULD be employed by an aggregator to communicate to receivers of a Compound Flow not only its common inclusion criteria, i.e. having matched the Aggregation Rule's selection patterns, but also its common exclusion criteria, i.e. not having matched any Preceding Rule's selection patterns. IPFIX extensions that enable efficient transport of such information are introduced in [I-D.sommer-ipfix-mediator-ext]. 6.3. Deriving Templates from Aggregation Rules With the definition of an Aggregation Rule as being comprised of one instruction per Compound Flow field, each Aggregation Rule unambiguously defines the structure of these Compound Flows. As Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 8] Internet-Draft IPFIX Flow Aggregation July 2008 illustrated in Table 2, all selection patterns of an Aggregation Rule become Common Properties of associated Compound Flows. With the exception of fields that are discarded, all fields of an Aggregation Rule transmit specific properties of Compound Flows and will thus need to be included in each exported Flow Record. Of those fields, all fields, except those that were aggregated, form the Flow Key of Compound Flows, as defined in [I-D.ietf-ipfix-architecture]. +-----------+-------------+---------------+---------------+---------+ | Selection | Aggregation | Common | Specific | Flow | | | | Property | Property | Key | +-----------+-------------+---------------+---------------+---------+ | any | discard | | | | | any | keep | | x | x | | any | mask | | x | x | | any | aggregate | | x | | | pattern | discard | x | | | | pattern | keep | x | x | x | | pattern | mask | x | x | x | | pattern | aggregate | x | x | | +-----------+-------------+---------------+---------------+---------+ Table 2: Mapping Rules to Templates It should be noted that certain combinations of selection and aggregation instructions can cause undesirable side effects and SHOULD NOT be used. These combinations are: atomic pattern, do not discard: Selecting Flows to only allow a specific field value (as opposed to a range of values) and retaining this field as a discriminating property will lead to the transmission of the selection pattern as both a Common Property of all Compound Flows and a discriminating property. If only an atomic pattern is used, the field can be discarded with no loss of information. any field value, discard: If neither a pattern nor a field modifier should apply to a field, it is sufficient for an Aggregation Rule to not include an instruction for this field. Specifying for a field neither a pattern nor a modifier will mandate presence of the field for an incoming Flow to be eligible for aggregation, but not accomplish any real selection or aggregation. pattern, aggregate: Selecting Flows to only allow certain field values in non- discriminating properties, such as packet counters, then modifying these properties, can lead to semantic conflicts when interpreting Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 9] Internet-Draft IPFIX Flow Aggregation July 2008 the received Compound Flows. 7. Example An Aggregation Rule shown in Table 3 will set up a stream of Compound Flows, creation of which is performed as follows. Selection: Only Flows containing at least fields for the source address, destination address, destination port, and the packet count will be considered for aggregation. In addition, the destination address must be in the subnet 192.0.2.0/28 and the destination port must be equal to 80. Compound Flow creation: Destination addresses are merged according to subnets in 192.0.2.0/30 and all packet counters of one Compound Flow are added up. Export: The resulting Compound Flow Records comprise the source address, the destination subnet address, and the packet counter as their specific properties, as well as a destination subnet of 192.0.2.0/28 and a destination port of 80 as their Common Property. +--------------------------+--------------+----------------+ | IPFIX Field | Selection | Aggregation | +--------------------------+--------------+----------------+ | sourceIPv4Address | | keep | | destinationIPv4Address | 192.0.2.0/28 | mask to 30 bit | | destinationTransportPort | 80 | discard | | packetDeltaCount | | aggregate | +--------------------------+--------------+----------------+ Table 3: Example Aggregation Rule Adding the Aggregation Rule shown in Table 4 and configuring it with a Preceding Rule, the Aggregation Rule of Table 3, will set up a second stream of Compound Flows, creation of which is performed as follows. Selection: As introduced in Section 6.2, Flows that were already aggregated according to the Preceding Rule will be skipped. In addition, only Flows containing at least fields for the source address, destination address, destination port, and the packet count will Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 10] Internet-Draft IPFIX Flow Aggregation July 2008 be considered for aggregation. Furthermore, the destination port of incoming Flows must be equal to 80. Compound Flow creation: Source and destination addresses are merged according to subnets in 192.0.2.0/30 and all packet counters of one Compound Flow are added up. Export: The resulting Compound Flow Records comprise the source subnet address, the destination subnet address, and the packet counter as their specific properties, as well as a destination port of 80 as their Common Property. Furthermore, a Common Property of all Compound Flow Records is that they did not match the Preceding Rule, i.e. the combination of their destination subnet and destination port was not 192.0.2.0/28 and 80. +--------------------------+-----------+----------------+ | IPFIX Field | Selection | Aggregation | +--------------------------+-----------+----------------+ | sourceIPv4Address | | mask to 30 bit | | destinationIPv4Address | | mask to 30 bit | | destinationTransportPort | 80 | discard | | packetDeltaCount | | aggregate | +--------------------------+-----------+----------------+ Table 4: Second Aggregation Rule (Chained) The following example Table 5 illustrates the application of the described chain of Aggregation Rules to selected Flows. +-------------+-----------+--------------+----------------+---------+ | Source IP | Source | Destination | Destination | Packets | | | Port | IP | Port | | +-------------+-----------+--------------+----------------+---------+ | 192.0.2.1 | 64235 | 192.0.2.101 | 80 | 10 | | 192.0.2.2 | 64236 | 192.0.2.102 | 110 | 10 | | 192.0.2.3 | 64237 | 192.0.2.103 | 80 | 10 | | 192.0.2.101 | 64238 | 192.0.2.1 | 80 | 10 | | 192.0.2.102 | 64239 | 192.0.2.2 | 80 | 10 | +-------------+-----------+--------------+----------------+---------+ Table 5: Incoming Flows Two sets of Compound Flows, as depicted in Table 6 and Table 7, will be exported in our example according to the Aggregation Rules shown in Table 3 and Table 4, respectively. Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 11] Internet-Draft IPFIX Flow Aggregation July 2008 +-------------+----------------+------------------+---------+ | Source IP | Destination IP | Destination Port | Packets | +-------------+----------------+------------------+---------+ | 192.0.2.101 | 192.0.2.0 | 80 | 10 | | 192.0.2.102 | 192.0.2.0 | 80 | 10 | +-------------+----------------+------------------+---------+ Table 6: Compound Flows according to the first Aggregation Rule +-----------+----------------+------------------+---------+ | Source IP | Destination IP | Destination Port | Packets | +-----------+----------------+------------------+---------+ | 192.0.2.0 | 192.0.2.100 | 80 | 20 | +-----------+----------------+------------------+---------+ Table 7: Compound Flows according to the second Aggregation Rule 8. Open Issues While the aggregation methodology introduced in Section 3 solves most problems that could arise when doing Flow aggregation, some issues are left unresolved. These issues require special attention or need to be addressed at higher layers and are presented in this section. One problem arises when received Option Data Records are forwarded by an aggregator. Option Data Records that refer to an Observation Domain, e.g. Data Records based on the Metering Process (Reliability) Statistics Option Template, only include an observationDomainId. However, [RFC5102] only mandates that the observationDomainId be locally unique to an Exporting Process, so in order to unambiguously refer to an Observation Domain, an additional identifier of the Exporting Process would need to be transmitted. While the selection of an Observation Domain ID that is unique to the aggregation domain would alleviate this issue, a more generic solution seems to be preferable. Another problem arises when different sources transmit Flows containing merely pseudonyms instead of IP addresses, and these Flows are to be aggregated e.g. by an IPFIX concentrator. If an aggregator is not explicitly informed of the anonymous nature of received Flows, it assumes that identical IP address values refer to identical hosts, which might not be the case if Flow sources employ different algorithms to generate pseudonyms. Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 12] Internet-Draft IPFIX Flow Aggregation July 2008 9. Security Considerations As all methods described in this document are merely variations on methods already introduced in [RFC5101], the same security considerations regarding exchange of Flow information apply. 10. IANA Considerations This document has no actions for IANA. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. 11.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-12 (work in progress), September 2006. [I-D.sommer-ipfix-mediator-ext] Sommer, C., Dressler, F., and G. Muenz, "Mediator-Specific Extensions to IPFIX Protocol and Information Model", draft-sommer-ipfix-mediator-ext-01 (work in progress), July 2008. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004. Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 13] Internet-Draft IPFIX Flow Aggregation July 2008 Authors' Addresses Falko Dressler University of Erlangen-Nuremberg 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-Nuremberg Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27993 Email: christoph.sommer@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/~sommer/ Gerhard Muenz University of Tuebingen Computer Networks and Internet Sand 13 Tuebingen 72076 Germany Phone: +49 7071 29-70534 Email: muenz@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/ Atsushi Kobayashi NTT Information Sharing Platform Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Phone: +81-422-59-3978 Email: akoba@nttv6.net Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 14] Internet-Draft IPFIX Flow Aggregation July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dressler, et al. draft-dressler-ipfix-aggregation-05.txt [Page 15]