IP Flow Information Export WG G. Muenz Internet-Draft University of Tuebingen Expires: January 4, 2009 L. Braun Technische Universitaet Muenchen July 3, 2008 Lossless Compression for IP Flow Information Export (IPFIX) 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 4, 2009. Abstract In this document, we discuss the benefits and possible realizations of IPFIX traffic compression. Experiments with real measurement data show that a significant compression gain can be achieved by applying the DEFLATE compression method to IPFIX data sets. Compression of IPFIX traffic can be based on underlying transport protocols, such as IPComp and TLS/DTLS, or realized as an extension of the IPFIX protocol. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 1] Internet-Draft IPFIX Compression July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reduction and Compression of Measurement Data . . . . . . . . 3 3.1. IPFIX Data Reduction Mechanisms . . . . . . . . . . . . . 4 3.2. Lossless Compression of Mesurement Data . . . . . . . . . 4 4. Gain of IPFIX Compression . . . . . . . . . . . . . . . . . . 5 4.1. University Network Flow Compression . . . . . . . . . . . 6 4.2. ISP Backbone Flow Compression . . . . . . . . . . . . . . 7 4.3. Packet Report Compression . . . . . . . . . . . . . . . . 7 5. Possible Realization of IPFIX Compression . . . . . . . . . . 8 5.1. Compressed IPsec Tunnel . . . . . . . . . . . . . . . . . 9 5.2. TLS/DTLS Compression . . . . . . . . . . . . . . . . . . . 9 5.3. Compressed IPFIX Messages . . . . . . . . . . . . . . . . 9 5.4. Compressed Data Sets . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 2] Internet-Draft IPFIX Compression July 2008 1. Introduction Exporting measurement data with low bandwidth utilization was not a primary design goal of the IPFIX protocol. Indeed, bandwidth efficiency is not mentioned in [RFC3917]. Although the separation of Templates and Data Records and the binary encoding prevents unnecessary inflation of the exported Flow information, the underlying mechanisms were mainly motivated by the objective to simplify the work of the IPFIX Exporter. However, bandwidth efficient export of Flow information is very beneficial in practice. If it was possible to export the same information with significantly reduced data volume (in terms of number of bytes), we could enjoy the following advantages: o It would be possible to utilize links with smaller bandwidth between Exporters and Collectors. o Network congestion could be avoided which reduces the loss ratio if UDP or PR-SCTP are used as transport protocol. o Less network I/O performance would be required at both, Exporters and Collectors. Similarly, the sender and receiver buffer sizes of the Exporters and Collectors could be reduced. This document discusses different options how the volume of exported Flows can be reduced without information loss. Particularly, we will show that lossless compression methods enable significant data volume reduction. Section 3 gives an overview on existing approaches and methods to reduce and compress traffic measurement data. Subsequently, Section 4 presents measurement results showing the high compressibility of IPFIX Data Sets containing Flow Records or Packet Records. Finally, Section 5 describes different ways how compression methods can be applied to the IPFIX protocol. 2. Terminology This document adopts the terminologies used in [RFC5101], [I-D.ietf-ipfix-file], and [I-D.ietf-psamp-protocol]. As in [RFC5101], these specific terms have the first letter of a word capitalized when used in this document. 3. Reduction and Compression of Measurement Data This section summarizes existing approaches of lossless reduction and compression of measurement data. Section 3.1 starts with a summary of existing IPFIX data reduction mechanisms. Section 3.2 presents other existing work applying lossless compression methods to measurement data. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 3] Internet-Draft IPFIX Compression July 2008 3.1. IPFIX Data Reduction Mechanisms The IPFIX protocol and its standardized extensions provide three different mechanisms to reduce the amount of exported data without loss of information: Reduced size encoding: As specified in [RFC5101], integer and float types can be encoded with reduced size if the smaller field size is sufficient to carry the exported values. The actual encoding size of a field in a Flow Record is defined by the field length in the Template definition. The application of reduced size encoding requires the definition of an appropriate Template. Data reduction by separation of common properties: Flows and packets observed in a network often share common properties. In order to avoid the repeated export of common properties with every Flow or Packet Record, common properties can be exported once for all Flows or packets in a separate Data Record defined by an Option Template. How this can be realized is described in [I-D.ietf-ipfix-reducing-redundancy]. With respect to data reduction, this approach is very limited and difficult to implement. The definition of common properties requires that Flows or packets share exactly the same values for a given set of Information Elements. Redundancy among different Information Elements, for example within the same Flow or among different Flows, cannot be reduced. Redundancy of values which are very similar but not identical cannot be reduced either. Finally, dynamically identifying common properties in a stream of Data Records and estimating the probability of reappearance in the future is difficult. Therefore, this data reduction approach is mainly useful if the existence of certain common properties in the Flows or packets is known a priori. Export of bidirectional Flows: The export of bidirectional Flow (Biflow) information as specified in [RFC5153] reduces the number of exported records if bidirectional traffic is observed. A Biflow Record is larger than a Flow Record because it contains additional fields of Reverse Information Elements, typically carrying measurement data about the reverse Flow direction. A Biflow Record may also contain the biflowDirection Information Element to indicate the initiator of the Biflow. In most cases, a small data reduction can be achieved because the Flow Key is exported only once for both directions. 3.2. Lossless Compression of Mesurement Data We are aware of the following approaches which deployed general purpose compression methods to reduce the amount of measurement data Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 4] Internet-Draft IPFIX Compression July 2008 sent from a traffic monitor to a collector. nFlow: In 2004, Luca Deri proposed nFlow [nFlow] as an alternative to IPFIX and NetFlow. One feature was the export of compressed flow records using ZLIB [RFC1950] or GZIP [RFC1952] compressed data format. DiMAPI: DiMAPI (Distributed Monitoring Application Programming Interface) has been developed in the European IST project LOBSTER [LOBSTER]. It enables the transport of measurement data from distributed traffic sensors to analysis applications running on remote hosts. In [PMI08], the authors evaluate different compression methods used to reduce the amount of measurement data transferred over the network. 4. Gain of IPFIX Compression In order to circumstantiate the utility of applying compression methods to Flow information, we conducted several experiments using IPFIX Flow Records and PSAMP Packet Records collected in different networks. Therefore, we chose the well-known compression method DEFLATE which is specified in [RFC1951]. DEFLATE is based on LZ77 algorithm and Huffman coding. It is deployed in various Internet protocols and data formats, e.g. IMAP [RFC4978], IRIS [RFC4993], SIP and RTSP [RFC3320], and PNG [RFC2083]. We applied the DEFLATE [RFC1951] compression method to Data Sets containing different numbers of Data Records and calculated the compression ratios. Therefore, we determined the compressed size using the ZLIB compressed data format [RFC1950]. ZLIB provides a generic container for compressed data which can be used in combination with different compression methods. The ZLIB format prepends a header of two bytes specifying compression method and parameters, and appends a checksum of four bytes. Note that ZLIB is preferred to the alternative GZIP format [RFC1952] since header and trailer are shorter. We calculated the compression ratios including the ZLIB header and trailer bytes. In order to get the raw size of the compressed Data Sets, six bytes need to be subtracted from the figures indicated in the tables below, resulting in higher compression ratios. The results presented in the following subsections show that the compression gain is large for Flow Records and much smaller for Packet Records. Better compression can be achieved with larger Data Sets. However, the compressed data volume never exceeds the original size of the Data Sets in our experiments. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 5] Internet-Draft IPFIX Compression July 2008 4.1. University Network Flow Compression We applied DEFLATE to Flows measured at the router connecting the class B network of a university to the Internet at a link speed of 2.4 Gigabit per second. Using unsampled Cisco NetFlow, the router generates about 1,800 Flow Records per second in the evening hours (active timeout is 30 minutes). The Flow Records were re-encoded into IPFIX Data Sets using the Template shown in Table 1 below. The definition of the Information Elements can be found in [RFC5102]. +----------+--------------------------+--------+ | Field No | Information Element | Length | +----------+--------------------------+--------+ | 1 | sourceIPv4Address | 4 | | 2 | destinationIPv4Address | 4 | | 3 | sourceTransportPort | 2 | | 4 | destinationTransportPort | 2 | | 5 | protocolIdentifier | 1 | | 6 | octetDeltaCount (*) | 4 | | 7 | packetDeltaCount (*) | 4 | | 8 | flowStartSeconds | 4 | | 9 | flowEndSeconds | 4 | +----------+--------------------------+--------+ (*) reduced size encoding Table 1: Flow Template The total length of one Data Record is 29 bytes. The Set header adds another four bytes to the Data Set. In every compression run, the same 120,000 Flow Records were written into Data Sets of different length. The compression was applied to the entire Data Sets (i.e., Set header plus Data Records). Table 2 shows the results. As can be seen, the Data Set can be compressed to 15 percent or less of its original size. Data Sets with 100 Flow Records could even be compressed to 2.1 percent of the original size. +-----------------+--------------+------------------+---------------+ | Number of | Uncompressed | Compressed size | Mean | | Records per | size | (mean; min; max) | compression | | Data Set | | | ratio | +-----------------+--------------+------------------+---------------+ | 10 | 294 | 43.0; 38; 44 | 6.83 | | 20 | 584 | 45.5; 43; 48 | 12.83 | | 40 | 1164 | 49.2; 45; 51 | 23.65 | | 60 | 1744 | 53.9; 52; 56 | 32.35 | Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 6] Internet-Draft IPFIX Compression July 2008 | 100 | 2904 | 62.7; 61; 64 | 46.31 | +-----------------+--------------+------------------+---------------+ Table 2: University Network: Compression Results 4.2. ISP Backbone Flow Compression We repeated the experiment of Section 4.1 with Flows measured in the Gigabit backbone network of a regional ISP in Germany. The observed Flows contain a mixture of web traffic, mail traffic, database queries, VPN tunnels, dial-in traffic etc. The measurements were performed at a router using unsampled Cisco NetFlow with active and idle flow timeouts set to 150 seconds, resulting in about 300 Flow Records per second. As before, the Flow Records were converted into IPFIX Data Sets using the Template of Table 1. Encapsulating again 120,000 Flow Records into Data Sets of different length, we achieved the compression results shown in Table 3. As can be seen, the results are almost identical to those obtained in Section 4.1. +-----------------+--------------+------------------+---------------+ | Number of | Uncompressed | Compressed size | Mean | | Records per | size | (mean; min; max) | compression | | Data Set | | | ratio | +-----------------+--------------+------------------+---------------+ | 10 | 294 | 43.1; 39; 46 | 6.82 | | 20 | 584 | 45.6; 41; 48 | 12.80 | | 40 | 1164 | 49.7; 45; 52 | 23.42 | | 60 | 1744 | 54.0; 50; 57 | 32.29 | | 100 | 2904 | 63.4; 59; 66 | 45.80 | +-----------------+--------------+------------------+---------------+ Table 3: ISP Backbone Network: Compression Results 4.3. Packet Report Compression As specified in [I-D.ietf-psamp-protocol], the IPFIX protocol can be used to export PSAMP Packet Reports. In order to evaluate the compression gain that can be achieved with Packet Records, we compressed Data Sets containing IP packet header sections covering the IP and transport layer headers. The Template definition is shown in Table 4 below. The definition of the Information Elements can be found in [I-D.ietf-psamp-info]. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 7] Internet-Draft IPFIX Compression July 2008 +----------+------------------------+----------+ | Field No | Information Element | Length | +----------+------------------------+----------+ | 1 | observationTimeSeconds | 4 | | 2 | ipHeaderPacketSection | variable | +----------+------------------------+----------+ Table 4: Packet Report Template 120,000 packets were captured in the network of a research institute. The resulting Packet Records were encapsulated in Data Sets of different length. Table 5 shows the original and compressed lengths of the Data Sets as well as the compression ratios. As can be seen, the compression ratio stays below 2 even for a large number of Packet Records per Data Set. Obviously, Packet Records are much less compressible than Flow Records. The huge difference can be explained by the fact that Flow Records usually contain packet header fields where the observed values are very redundant. +---------------+-------------------+-----------------+-------------+ | Number of | Uncompressed size | Compressed size | Mean | | Records per | (mean; min; max) | (mean; min; | compression | | Data Set | | max) | ratio | +---------------+-------------------+-----------------+-------------+ | 10 | 405.5; 302; 574 | 318.3; 172; 437 | 1.27 | | 20 | 807.0; 656; 1144 | 575.0; 341; 744 | 1.40 | | 40 | 1610.1; 1324; | 1029.9; 615; | 1.56 | | | 2260 | 1274 | | | 60 | 2413.1; 2056; | 1451.9; 889; | 1.66 | | | 3376 | 1771 | | | 100 | 4019.3; 3512; | 2275.4; 1769; | 1.76 | | | 5004 | 2675 | | +---------------+-------------------+-----------------+-------------+ Table 5: Packet Reports: Compression Results 5. Possible Realization of IPFIX Compression In this section, we discuss different options that allow applying compression methods to IPFIX traffic. At first, we describe two solutions which are based on compression options provided by IPComp and DTLS. As third and fourth option, we propose IPFIX-specific solutions which do not depend on the underlying transport protocol, but require extensions of the IPFIX protocol. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 8] Internet-Draft IPFIX Compression July 2008 5.1. Compressed IPsec Tunnel IP payload compression (IPComp) [RFC3173] enables the compression of IP datagrams exchanged between a pair of communicating nodes. Therefore, an IPComp association (IPCA) between the two nodes must be established. DEFLATE [RFC2394] and Lempel-Ziv-Stac (LZS) [RFC2395] are among the standardized compression methods. IPComp has been conceived for compressing IP datagrams before sending them over an encrypted tunnel. Dynamic negotiation of IPCAs has been standardized as part of the Internet Key Exchange protocol (IKE) [RFC4306]. If IPFIX traffic is transported over an IPsec tunnel, IPComp may be used for compression. In this case, the compression is transparent to both, Exporting Process and Collecting Process. 5.2. TLS/DTLS Compression TLS [RFC4346] and DTLS [RFC4347] enable the negotiation and deployment of a lossless compression method. Two compression methods have been standardized for usage with TLS: DEFLATE [RFC3749] and Lempel-Ziv-Stac (LZS) [RFC3943]. For DTLS, no compression methods have been standardized, yet. RFC 3749 [RFC3749] recommends the usage of stateful compression for TLS, which means that a compression history across packets is maintained to achieve higher compression ratios. DTLS has been conceived for transport protocols that do not guarantee reliable, sequenced packet delivery. In this case, only stateless per-packet compression is possible. For example, DEFLATE and LZS could be applied on a per-packet basis. The IPFIX protocol specification [RFC5101] mandates the support of DTLS if SCTP or UDP are used as transport protocol for IPFIX. Similarly, if TCP is used as transport protocol, TLS must be supported. Although no compression method has been standardized for DTLS, DEFLATE [RFC1951] can be used for stateless compression of individual SCTP messages or UDP datagrams. The utilization of DTLS or TLS is not mandated by the IPFIX protocol. If DTLS or TLS are employed, compression methods may be negotiated and deployed between the Exporting Process and the Collecting Process. 5.3. Compressed IPFIX Messages A compressed variant of the IPFIX Message format could be designed as follows. The IPFIX Message header remains uncompressed and is structured as defined in Section 3.1 of [RFC5101]. The message payload following the IPFIX Message header is compressed using DEFLATE as specified in [RFC1951]. Optionally, the ZLIB format Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 9] Internet-Draft IPFIX Compression July 2008 [RFC1950] could be used to enable the choice of alternative compression methods and to protect the data integrity by a checksum. In order to distinguish compressed IPFIX Messages from normal IPFIX Messages, a new IPFIX Version Number must be used for compressed IPFIX Messages, for example 0x000b. Leaving the IPFIX Message header uncompressed facilitates the work of both, Exporting Processes and Collecting Processes. The version number and length field are required to decode the message correctly. The Exporting Process does not know in advance how much time the compression will require. Keeping the export time in the IPFIX Message Header allows the Exporting Process to fill this field after compressing the message payload. Finally, the uncompressed Observation Domain ID allows the Collecting Process to classify IPFIX Messages before decompressing the message payload. 5.4. Compressed Data Sets Instead of compressing the entire payload of IPFIX Messages, it is also possible to introduce a new Set type called Deflate Template Set. Just like normal Template Sets, the Deflate Template Set is used to carry Templates, namely Deflate Templates. The format of Deflate Template Records is the same as the Template Record format specified in Section 3.4.1 of [RFC5101]. However, the corresponding Data Sets differ: starting with the first byte after the Set header, the sequence of Deflate Data Records is compressed using DEFLATE [RFC1951]. Again, the ZLIB format [RFC1950] could be used to enable the choice of alternative compression methods and to protect the data integrity by a checksum. The Set header remains uncompressed and includes the length of the Set after compression. In order to distinguish Deflate Template Sets from other Sets, a new Set ID value must be specified (e.g., Set ID = 4). Compression at the level of Data Sets is more flexible than the compression of IPFIX Messages as described in Section 5.3 since it allows exporting compressed and uncompressed Records within a single IPFIX Message. On the other hand, the size of the compressed data blocks is smaller, which usually results in lower compression ratios. 6. Security Considerations The same security considerations as for the IPFIX protocol [RFC5101] apply. The protocol extensions discussed in Section 5.3 and Section 5.4 introduce additional security issues for the Collector. An attacker may send forged compressed IPFIX Messages or Data Sets to the Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 10] Internet-Draft IPFIX Compression July 2008 Collector which require very large amount of memory after decompression, leading to possible memory exhaustion. The decompression of such data may also require enormous processing resources, causing a temporary denial of service. The Collector must implement a protection mechanism which ensures that the decompression is interrupted if it spends large amount of memory or runtime. 7. IANA Considerations The two compression solutions described in Section 5.3 and Section 5.4 require the assignment of a new IPFIX Version Number or IPFIX Set ID respectively. As specifed in [RFC5101], the standardization of these solutions requires a Standards Action [RFC2434]. 8. References 8.1. Normative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [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. [I-D.ietf-ipfix-file] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "An IPFIX-Based File Format", draft-ietf-ipfix-file-01 (work in progress), February 2008. [I-D.ietf-psamp-protocol] Claise, B., "Packet Sampling (PSAMP) Protocol Specifications", draft-ietf-psamp-protocol-09 (work in progress), December 2007. [I-D.ietf-psamp-info] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", draft-ietf-psamp-info-08 (work in progress), Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 11] Internet-Draft IPFIX Compression July 2008 February 2008. 8.2. Informative References [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. [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IPFIX Implementation Guidelines", RFC 5153, April 2008. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, "GZIP file format specification version 4.3", RFC 1952, May 1996. [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998. [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998. [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, November 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 12] Internet-Draft IPFIX Compression July 2008 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [nFlow] Deri, L., "nFlow: Monitoring Flows on IPv4/v6 Networks", TERENA Networking Conference 2004, June 2004. [LOBSTER] "IST LOBSTER Project Homepage", Homepage http://www.ist-lobster.org, 2008. [PMI08] Politopoulos, P., Markatos, E., and S. Ioannidis, "Evaluation of Compression of Remote Network Monitoring Data Streams", IEEE Workshop on End-to-End Monitoring Techniques and Services E2EMON 2008, April 2008. [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, August 2007. [RFC4993] Newton, A., "A Lightweight UDP Transfer Protocol for the Internet Registry Information Service", RFC 4993, August 2007. [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [RFC2083] Boutell, T., "PNG (Portable Network Graphics) Specification Version 1.0", RFC 2083, March 1997. Authors' Addresses Gerhard Muenz University of Tuebingen Computer Networks and Internet Sand 13 Tuebingen D-72076 DE Phone: +49 7071 29-70534 Email: muenz@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/~muenz Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 13] Internet-Draft IPFIX Compression July 2008 Lothar Braun Technische Universitaet Muenchen Network Architectures and Services, Institute for Informatics Boltzmannstrasse 3 Garching D-85748 DE Phone: +49 89 289-18010 Email: braun@net.in.tum.de URI: http://www.net.in.tum.de/ Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 14] Internet-Draft IPFIX Compression 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. Muenz & Braun draft-muenz-ipfix-compression-00.txt [Page 15]