Network Working Group C. Sommer Internet-Draft F. Dressler Expires: May 15, 2008 Univ. Erlangen G. Muenz Univ. Tuebingen November 12, 2007 Mediator-Specific Extensions to IPFIX Protocol and Information Model 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 May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IPFIX supports the concept of an Mediator, a device that receives, transforms, and exports data streams using IPFIX. One of the most important requirements is the reduction of the volume of IPFIX traffic by discarding and aggregating received information. This document introduces a number of extensions to the IPFIX Protocol and IPFIX Information Model that support the export of aggregated IPFIX Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 1] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 data. In particular, techniques are introduced that optimize the transport of descriptive information. Thus, more information can be preserved in the transmission while further reducing both the number and the size of IPFIX messages. All the proposed extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rich Template . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Abstract data type ipv4Network . . . . . . . . . . . . . . . . 10 5. Abstract data type portRanges . . . . . . . . . . . . . . . . 10 6. excludedPropertiesId Information Element . . . . . . . . . . . 11 7. precedingRulePropertiesId Information Element . . . . . . . . 13 8. Security considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 2] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 1. Introduction The IPFIX Mediator is intended to provide techniques and features to process IPFIX data in a Mediation Process. This process receives data streams using IPFIX. It can apply transformations or aggregation techniques and forward the resulting Flow information to an Exporting Process and, thus, to another IPFIX collector. Flow aggregation is one of the most challenging and important operations in high-bandwidth networks. The main idea is to reduce both the number and the size of IPFIX messages. This document introduces extensions to the IPFIX Protocol and IPFIX Information Model that support the export of aggregated IPFIX data. In particular, a new Template type is introduced and additional Information Elements are described. All these extensions allow and optimize the transport of descriptive information on aggregated IPFIX data. Thus, more information can be preserved in the transmission while further reducing both the number and the size of IPFIX messages. All the proposed extensions are directly applicable to the IPFIX Mediator but can be used in many different applications as well. 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]. Illustrations of abstract data types are written in Augmented Backus- Naur Form (ABNF), as specified in [RFC4234], extending the abstract data types defined in [I-D.ietf-ipfix-info]. 2. Terminology Apart from the basic terms as defined in [I-D.ietf-ipfix-protocol], 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. Aggregation Rule: An Aggregation Rule defines the properties of a Compound Flow and the contents of the corresponding Flow Records. Optionally, a set of filtering criteria MAY be specified in order to restrict the applicability of the rule to those Flows that show certain patterns. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 3] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 3. Rich Template [I-D.dressler-ipfix-aggregation] describes how pattern matching is used to restrict the applicability of an Aggregation Rule and how patterns define Common Properties of the resulting Compound Flows. In order to avoid the overhead of the repeated transmissions of all Common Properties (or their identifiers) in all Flow Records, a new Template Set, the "Rich Template Set" is introduced. This Template Set allows an Exporting Process to simultaneously declare and transmit Common Properties to a receiver. The basic format of a Rich Template Set is shown in Figure 1. It is the same as that of a Template Set defined in [I-D.ietf-ipfix-protocol], except for a different Set ID. The format of individual Rich Template Records, however, differs from that of Template Records and is shown in Figure 2. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Rich Template Record 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Rich Template Record N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Rich Template Set Format The Rich Template Set field definitions are as follows: Set ID Type of this Template Set. A Set ID value of 4 is proposed for the Rich Template Set. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 4] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 Length Total length of this set in bytes, as defined in [I-D.ietf-ipfix-protocol]. Padding OPTIONAL padding, as defined in [I-D.ietf-ipfix-protocol]. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 5] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 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 (> 255) | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Count | Common Properties ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field 1 Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field N Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Specifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Rich Template Record Format The Rich Template Record field definitions are as follows: Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 6] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 Template ID Template ID of this Rich Template Record. As defined in [I-D.ietf-ipfix-protocol], this value MUST be greater than 255. Field Count Number of regular fields that will be sent in subsequent Data Records using this Template, as defined in [I-D.ietf-ipfix-protocol]. Data Count Number of fixed-value fields that will be sent in this Template. Common Properties ID Contains an identifier that can be referred to by commonPropertiesId Information Elements, as introduced in [I-D.ietf-ipfix-reducing-redundancy]. Field N Specifier Information Element identifier, Field length and an Enterprise Number (if applicable) of field N. Refer to [I-D.ietf-ipfix-protocol] for more information on Field Specifiers. Data M Specifier Same as "Field N Specifier", but used for Common Properties of all Data Records of this Template. Together with Data M Value, a similar encoding like TLV (type-length-value) is achieved. Data M Value Bit representation of a Common Property as would be transmitted in a Data Record. Table 1 illustrates the relationship between field modifiers and patterns on the one hand, and the resulting regular and fixed-value fields in the Rich Template on the other hand. It can be seen that the analyzer is able to deduce all instructions of the Aggregation Rule considering the structure of the Rich Template, except the combination "discard without pattern" that does not result in any field. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 7] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 +----------+---------+------------------------+---------------------+ | field | pattern | field in Flow Record | fixed-value field | | modifier | | | in Rich Template | +----------+---------+------------------------+---------------------+ | discard | no | N/A | N/A | | discard | yes | N/A | yes, contains | | | | | pattern | | keep | no | yes | N/A | | keep | yes | yes, if pattern | yes, contains | | | | specifies a range of | pattern | | | | values | | | mask | no | yes, IP network | N/A | | | | address | | | mask | yes | yes, IP network | yes, contains | | | | address | pattern | +----------+---------+------------------------+---------------------+ Table 1: Relation between field modifiers, Flow Records, and Rich Templates Assume, for example, the concentrator was given the Aggregation Rule shown in Table 2. +-------------------------+--------------+-------------+ | IPFIX Field | Filtering | Aggregation | +-------------------------+--------------+-------------+ | sourceIPv4Address | 192.0.2.0/28 | discard | | destinatonTransportPort | | keep | | packetDeltaCount | | aggregate | +-------------------------+--------------+-------------+ Table 2: Example Rule Based on the Aggregation Rule, the concentrator would now first send a corresponding Rich Template Record as shown in Table 3. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 8] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 +----------------------+------------------+ | Field | Value | +----------------------+------------------+ | Template ID | 10001 | | Field Count | 2 | | Data Count | 2 | | Common Properties ID | 0 | | Field 1 Type | Destination Port | | Field 2 Type | Packets | | Data 1 Type | Source IP Prefix | | Data 2 Type | Source IP Mask | | Data 1 Value | 192.0.2.0 | | Data 2 Value | 28 | +----------------------+------------------+ Table 3: Rich Template used Assume further that the concentrator receives the Flow Records shown in Table 4. +-------------+-----------+--------------+----------------+---------+ | 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 4: Incoming Flows The concentrator would then export Data Records of this type, which contain the Compound Flows resulting from aggregation. Note that the Flows' Common Property, having a source IP address in 192.0.2.0/28, was already transmitted in the Rich Template Record and is thus not included in Data Records. The exported Data Records, shown in Table 5, only contain the aggregated packet counts and the destination port, the latter being the only discriminating Flow Key property. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 9] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 +------------------+---------+ | Destination Port | Packets | +------------------+---------+ | 80 | 20 | | 110 | 10 | +------------------+---------+ Table 5: Aggregated Flows 4. Abstract data type 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. The ipv4Network abstract data type extends the abstract data type ipv4Address to allow a concatenated unsigned8 specifying the prefix length. Alternatively, Information Elements based on the ipv4Network abstract data type MAY be transmitted using reduced size encoding to transmit only the network part of an IPv4 address. In ABNF-style notation, the syntax can be summed up as follows: ipv4Network = ipv4Address unsigned8 ipv4Network =/ *4( unsigned8 ) Although using an ipv4Network field instead of two separate fields for prefix and mask will not reduce the length of resulting Flow Records, it eases the work of the aggregator: With ipv4Network, the comparison of subnet addresses requires only one field lookup per Flow Record instead of two. Furthermore, using the abstract data type ipv4Network reduces the Template size by one field equalling four octets. Applications such as IPFIX Aggregation benefit from ipv4Network if network addresses are frequently exported. 5. Abstract data type portRanges For some applications it might be useful to restrict the applicability of an Aggregation Rule to Flows with source or destination port being of a specific set of port numbers. In an Aggregation Rule, such a set of port numbers can be specified as a pattern. However, the current IPFIX Information Model does not define any data type that allows transmitting a set of port numbers, which is necessary in order to export the pattern as a Common Property of the resulting Compound Flows. Therefore, the new abstract data type portRanges for a list of port ranges is defined in Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 10] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 this section. The abstract data type portRanges is a finite-length concatenation of unsigned16 value pairs, each consisting of the port range's first and last port number. Data types basing on portRanges MAY also be cast down to unsigned16 using reduced size encoding to represent a single Port. Hence, the transportSourcePort and transportDestinationPort data types, currently based on the unsigned16 abstract data type, can also be parsed as portRanges-based data types. In ABNF-style notation, the syntax can be summed up as follows: portRanges = *(unsigned16 unsigned16) portRanges =/ unsigned16 An Information Element basing on portRanges MAY also be used as a variable-length Information Elements by prefixing it with a one-octet or three-octet length specifier as defined in [I-D.ietf-ipfix-protocol]. Table 6 shows some encoding examples with portRanges. +---------------+--------+-------------------------------+ | Port Ranges | Octets | 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 6: PortRanges Examples 6. excludedPropertiesId Information Element The IPFIX Information Model [I-D.ietf-ipfix-info] defines the commonPropertiesId Information Element, which can be used to link to information which several Flows have in common. Similarly, the excludedPropertiesId shall be defined to link to a set of Common Properties which a Flow does explicitly not exhibit. An ElementId of 239 is proposed for this Information Element. The excludedPropertiesId works like a boolean "and not" operation on the linked properties. This means that, if an excludedPropertiesId refers to a set of Common Properties which in turn specifies excluded Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 11] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 properties, these transitively referenced properties are to be treated as if directly referenced via a commonPropertiesId element and, hence, as being present in the Flow in question. The excludedPropertiesId can, for example, be used when a hierarchy of Aggregation Rules with a "preceding rule" semantic, as introduced in [I-D.dressler-ipfix-aggregation], is configured in an IPFIX Aggregator. Figure 5 illustrates the use of Common Property definitions and the linking to these definitions with Information Elements of types commonPropertiesId (CP) and excludedPropertiesId (EP). In this example, two rules are defined in the aggregator: Rule 1 matches Flows with a sourceIPv4Address of 192.0.2.1, Rule 2 matches Flows with a destinationIPv4Address of 192.0.2.2. Furthermore, Rule 1 is configured to precede Rule 2 in a hierarchy of rules, i.e. Flows that matched Rule 1 will never match Rule 2. In order to communicate this fact to a receiver, each Aggregation Rule is transmitted as two sets of Common Properties. One set of properties (shown on the right hand side of Figure 5) directly transmits a rule's filtering criteria. The other set of properties (shown on the left hand side) refers via a commonPropertiesId to all properties that a Compound Flow exhibits, as well as via an excludedPropertiesId to all that the Compound Flow does not exhibit. The Flow depicted at the bottom of Figure 5 thus communicates a source port of 80, a destination port of 65432, a destination IP of 192.0.2.2 and a source IP of "not 192.0.2.1". However, besides the transmission of this Flow in one Data Record, previous transmissions (and the successful reception) of four Option Templates, four Option Data Records and one Template are required to communicate this information. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 12] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 Rule 1: +########+------+ +######+---------------+ # CP=101 # CP=1 |<-----------># CP=1 # SRC=192.0.2.1 | +########+------+ +######+---------------+ ^ .--------------------' Rule 2: v +########+------+------+ +######+---------------+ # CP=102 # EP=1 | CP=2 |<----># CP=2 # DST=192.0.2.2 | +########+------+------+ +######+---------------+ ^ '-------------------. Flow: v +--------+-----------+--------+ | SPT=80 | DPT=65432 | CP=102 | +--------+-----------+--------+ Figure 5: Using excludedPropertiesId to communicate a rule hierarchy 7. precedingRulePropertiesId Information Element The only aspect in which the precedingRulePropertiesId Information Element differs from the excludedPropertiesId Information Element introduced in Section 6 is that transitive references are handled differently. Unlike the excludedPropertiesId, the precedingRulePropertiesId does not work like a boolean "and not" operation on the linked properties. This means that, if a precedingRulePropertiesId refers to a set of Common Properties which in turn specifies excluded properties, these transitively referenced properties are to be treated as being excluded from the Flow in question, too. Analogous to excludedPropertiesId, the precedingRulePropertiesId (PP) Information Element can be used to communicate the hierarchy of rules introduced in the example of Section 6. As illustrated in Figure 6, the amount of data transmitted is now significantly smaller, while communicating the exact same information: A source port of 80, a destination port of 65432, a destination IP of 192.0.2.2 and a source IP of "not 192.0.2.1". Besides the transmission of the Flow in one Data Record it only requires the previous transmissions (and the successful reception) of two Rich Templates. Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 13] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 Rule 1: +---------------+ | SRC=192.0.2.1 |<---. (Rich Template 1234, CP=101) +---------------+ | | | Rule 2: | +---------------+--------+ | DST=192.0.2.2 | PP=101 | (Rich Template 1235) +---------------+--------+ Flow: +--------+-----------+ | SPT=80 | DPT=65432 | (Based on Rich Template 1235) +--------+-----------+ Figure 6: Using precedingRulePropertiesId to communicate a rule hierarchy 8. 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. 9. IANA Considerations Use of the Rich Template Set requires one new IPFIX Set ID to be assigned. Use of excludedPropertiesId, precedingRulePropertiesId, as well as use of a data type basing on ipv4Network or on portRanges requires one new IPFIX Information Element identifier each to be assigned. 10. References 10.1. Normative References [I-D.ietf-ipfix-protocol] Claise, B., "Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information", draft-ietf-ipfix-protocol-26 (work in progress), September 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 14] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 10.2. Informative References [I-D.dressler-ipfix-aggregation] Dressler, F., "IPFIX Aggregation", draft-dressler-ipfix-aggregation-03 (work in progress), June 2006. [I-D.ietf-ipfix-info] Quittek, J., "Information Model for IP Flow Information Export", draft-ietf-ipfix-info-15 (work in progress), February 2007. [I-D.ietf-ipfix-reducing-redundancy] Boschi, E., "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", draft-ietf-ipfix-reducing-redundancy-04 (work in progress), May 2007. Authors' Addresses 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/ Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 15] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 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/ 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/ Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 16] Internet-Draft Mediator-Specific IPFIX Extensions November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Sommer, et al. draft-dressler-ipfix-aggregation-04.txt [Page 17]