[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 4, 2009.


   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

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

   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

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.

              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.

              Claise, B., "Packet Sampling (PSAMP) Protocol
              Specifications", draft-ietf-psamp-protocol-09 (work in
              progress), December 2007.

              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

              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

   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

   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

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

   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

Muenz & Braun     draft-muenz-ipfix-compression-00.txt         [Page 15]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/