idnits 2.17.1 draft-muenz-ipfix-compression-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 637. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2008) is 5776 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-05) exists of draft-ietf-ipfix-file-01 == Outdated reference: A later version (-11) exists of draft-ietf-psamp-info-08 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Flow Information Export WG G. Muenz 3 Internet-Draft University of Tuebingen 4 Expires: January 4, 2009 L. Braun 5 Technische Universitaet Muenchen 6 July 3, 2008 8 Lossless Compression for IP Flow Information Export (IPFIX) 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 4, 2009. 36 Abstract 38 In this document, we discuss the benefits and possible realizations 39 of IPFIX traffic compression. Experiments with real measurement data 40 show that a significant compression gain can be achieved by applying 41 the DEFLATE compression method to IPFIX data sets. Compression of 42 IPFIX traffic can be based on underlying transport protocols, such as 43 IPComp and TLS/DTLS, or realized as an extension of the IPFIX 44 protocol. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Reduction and Compression of Measurement Data . . . . . . . . 3 53 3.1. IPFIX Data Reduction Mechanisms . . . . . . . . . . . . . 4 54 3.2. Lossless Compression of Mesurement Data . . . . . . . . . 4 56 4. Gain of IPFIX Compression . . . . . . . . . . . . . . . . . . 5 57 4.1. University Network Flow Compression . . . . . . . . . . . 6 58 4.2. ISP Backbone Flow Compression . . . . . . . . . . . . . . 7 59 4.3. Packet Report Compression . . . . . . . . . . . . . . . . 7 61 5. Possible Realization of IPFIX Compression . . . . . . . . . . 8 62 5.1. Compressed IPsec Tunnel . . . . . . . . . . . . . . . . . 9 63 5.2. TLS/DTLS Compression . . . . . . . . . . . . . . . . . . . 9 64 5.3. Compressed IPFIX Messages . . . . . . . . . . . . . . . . 9 65 5.4. Compressed Data Sets . . . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Intellectual Property and Copyright Statements . . . . . . . . . . 15 78 1. Introduction 80 Exporting measurement data with low bandwidth utilization was not a 81 primary design goal of the IPFIX protocol. Indeed, bandwidth 82 efficiency is not mentioned in [RFC3917]. Although the separation of 83 Templates and Data Records and the binary encoding prevents 84 unnecessary inflation of the exported Flow information, the 85 underlying mechanisms were mainly motivated by the objective to 86 simplify the work of the IPFIX Exporter. 88 However, bandwidth efficient export of Flow information is very 89 beneficial in practice. If it was possible to export the same 90 information with significantly reduced data volume (in terms of 91 number of bytes), we could enjoy the following advantages: 92 o It would be possible to utilize links with smaller bandwidth 93 between Exporters and Collectors. 94 o Network congestion could be avoided which reduces the loss ratio 95 if UDP or PR-SCTP are used as transport protocol. 96 o Less network I/O performance would be required at both, Exporters 97 and Collectors. Similarly, the sender and receiver buffer sizes 98 of the Exporters and Collectors could be reduced. 100 This document discusses different options how the volume of exported 101 Flows can be reduced without information loss. Particularly, we will 102 show that lossless compression methods enable significant data volume 103 reduction. Section 3 gives an overview on existing approaches and 104 methods to reduce and compress traffic measurement data. 105 Subsequently, Section 4 presents measurement results showing the high 106 compressibility of IPFIX Data Sets containing Flow Records or Packet 107 Records. Finally, Section 5 describes different ways how compression 108 methods can be applied to the IPFIX protocol. 110 2. Terminology 112 This document adopts the terminologies used in [RFC5101], 113 [I-D.ietf-ipfix-file], and [I-D.ietf-psamp-protocol]. As in 114 [RFC5101], these specific terms have the first letter of a word 115 capitalized when used in this document. 117 3. Reduction and Compression of Measurement Data 119 This section summarizes existing approaches of lossless reduction and 120 compression of measurement data. Section 3.1 starts with a summary 121 of existing IPFIX data reduction mechanisms. Section 3.2 presents 122 other existing work applying lossless compression methods to 123 measurement data. 125 3.1. IPFIX Data Reduction Mechanisms 127 The IPFIX protocol and its standardized extensions provide three 128 different mechanisms to reduce the amount of exported data without 129 loss of information: 131 Reduced size encoding: As specified in [RFC5101], integer and float 132 types can be encoded with reduced size if the smaller field size 133 is sufficient to carry the exported values. The actual encoding 134 size of a field in a Flow Record is defined by the field length in 135 the Template definition. The application of reduced size encoding 136 requires the definition of an appropriate Template. 138 Data reduction by separation of common properties: Flows and packets 139 observed in a network often share common properties. In order to 140 avoid the repeated export of common properties with every Flow or 141 Packet Record, common properties can be exported once for all 142 Flows or packets in a separate Data Record defined by an Option 143 Template. How this can be realized is described in 144 [I-D.ietf-ipfix-reducing-redundancy]. 145 With respect to data reduction, this approach is very limited and 146 difficult to implement. The definition of common properties 147 requires that Flows or packets share exactly the same values for a 148 given set of Information Elements. Redundancy among different 149 Information Elements, for example within the same Flow or among 150 different Flows, cannot be reduced. Redundancy of values which 151 are very similar but not identical cannot be reduced either. 152 Finally, dynamically identifying common properties in a stream of 153 Data Records and estimating the probability of reappearance in the 154 future is difficult. Therefore, this data reduction approach is 155 mainly useful if the existence of certain common properties in the 156 Flows or packets is known a priori. 158 Export of bidirectional Flows: The export of bidirectional Flow 159 (Biflow) information as specified in [RFC5153] reduces the number 160 of exported records if bidirectional traffic is observed. A 161 Biflow Record is larger than a Flow Record because it contains 162 additional fields of Reverse Information Elements, typically 163 carrying measurement data about the reverse Flow direction. A 164 Biflow Record may also contain the biflowDirection Information 165 Element to indicate the initiator of the Biflow. In most cases, a 166 small data reduction can be achieved because the Flow Key is 167 exported only once for both directions. 169 3.2. Lossless Compression of Mesurement Data 171 We are aware of the following approaches which deployed general 172 purpose compression methods to reduce the amount of measurement data 173 sent from a traffic monitor to a collector. 175 nFlow: In 2004, Luca Deri proposed nFlow [nFlow] as an alternative 176 to IPFIX and NetFlow. One feature was the export of compressed 177 flow records using ZLIB [RFC1950] or GZIP [RFC1952] compressed 178 data format. 180 DiMAPI: DiMAPI (Distributed Monitoring Application Programming 181 Interface) has been developed in the European IST project LOBSTER 182 [LOBSTER]. It enables the transport of measurement data from 183 distributed traffic sensors to analysis applications running on 184 remote hosts. In [PMI08], the authors evaluate different 185 compression methods used to reduce the amount of measurement data 186 transferred over the network. 188 4. Gain of IPFIX Compression 190 In order to circumstantiate the utility of applying compression 191 methods to Flow information, we conducted several experiments using 192 IPFIX Flow Records and PSAMP Packet Records collected in different 193 networks. Therefore, we chose the well-known compression method 194 DEFLATE which is specified in [RFC1951]. DEFLATE is based on LZ77 195 algorithm and Huffman coding. It is deployed in various Internet 196 protocols and data formats, e.g. IMAP [RFC4978], IRIS [RFC4993], SIP 197 and RTSP [RFC3320], and PNG [RFC2083]. 199 We applied the DEFLATE [RFC1951] compression method to Data Sets 200 containing different numbers of Data Records and calculated the 201 compression ratios. Therefore, we determined the compressed size 202 using the ZLIB compressed data format [RFC1950]. ZLIB provides a 203 generic container for compressed data which can be used in 204 combination with different compression methods. The ZLIB format 205 prepends a header of two bytes specifying compression method and 206 parameters, and appends a checksum of four bytes. Note that ZLIB is 207 preferred to the alternative GZIP format [RFC1952] since header and 208 trailer are shorter. We calculated the compression ratios including 209 the ZLIB header and trailer bytes. In order to get the raw size of 210 the compressed Data Sets, six bytes need to be subtracted from the 211 figures indicated in the tables below, resulting in higher 212 compression ratios. 214 The results presented in the following subsections show that the 215 compression gain is large for Flow Records and much smaller for 216 Packet Records. Better compression can be achieved with larger Data 217 Sets. However, the compressed data volume never exceeds the original 218 size of the Data Sets in our experiments. 220 4.1. University Network Flow Compression 222 We applied DEFLATE to Flows measured at the router connecting the 223 class B network of a university to the Internet at a link speed of 224 2.4 Gigabit per second. Using unsampled Cisco NetFlow, the router 225 generates about 1,800 Flow Records per second in the evening hours 226 (active timeout is 30 minutes). The Flow Records were re-encoded 227 into IPFIX Data Sets using the Template shown in Table 1 below. The 228 definition of the Information Elements can be found in [RFC5102]. 230 +----------+--------------------------+--------+ 231 | Field No | Information Element | Length | 232 +----------+--------------------------+--------+ 233 | 1 | sourceIPv4Address | 4 | 234 | 2 | destinationIPv4Address | 4 | 235 | 3 | sourceTransportPort | 2 | 236 | 4 | destinationTransportPort | 2 | 237 | 5 | protocolIdentifier | 1 | 238 | 6 | octetDeltaCount (*) | 4 | 239 | 7 | packetDeltaCount (*) | 4 | 240 | 8 | flowStartSeconds | 4 | 241 | 9 | flowEndSeconds | 4 | 242 +----------+--------------------------+--------+ 244 (*) reduced size encoding 246 Table 1: Flow Template 248 The total length of one Data Record is 29 bytes. The Set header adds 249 another four bytes to the Data Set. 251 In every compression run, the same 120,000 Flow Records were written 252 into Data Sets of different length. The compression was applied to 253 the entire Data Sets (i.e., Set header plus Data Records). Table 2 254 shows the results. As can be seen, the Data Set can be compressed to 255 15 percent or less of its original size. Data Sets with 100 Flow 256 Records could even be compressed to 2.1 percent of the original size. 258 +-----------------+--------------+------------------+---------------+ 259 | Number of | Uncompressed | Compressed size | Mean | 260 | Records per | size | (mean; min; max) | compression | 261 | Data Set | | | ratio | 262 +-----------------+--------------+------------------+---------------+ 263 | 10 | 294 | 43.0; 38; 44 | 6.83 | 264 | 20 | 584 | 45.5; 43; 48 | 12.83 | 265 | 40 | 1164 | 49.2; 45; 51 | 23.65 | 266 | 60 | 1744 | 53.9; 52; 56 | 32.35 | 267 | 100 | 2904 | 62.7; 61; 64 | 46.31 | 268 +-----------------+--------------+------------------+---------------+ 270 Table 2: University Network: Compression Results 272 4.2. ISP Backbone Flow Compression 274 We repeated the experiment of Section 4.1 with Flows measured in the 275 Gigabit backbone network of a regional ISP in Germany. The observed 276 Flows contain a mixture of web traffic, mail traffic, database 277 queries, VPN tunnels, dial-in traffic etc. The measurements were 278 performed at a router using unsampled Cisco NetFlow with active and 279 idle flow timeouts set to 150 seconds, resulting in about 300 Flow 280 Records per second. As before, the Flow Records were converted into 281 IPFIX Data Sets using the Template of Table 1. Encapsulating again 282 120,000 Flow Records into Data Sets of different length, we achieved 283 the compression results shown in Table 3. As can be seen, the 284 results are almost identical to those obtained in Section 4.1. 286 +-----------------+--------------+------------------+---------------+ 287 | Number of | Uncompressed | Compressed size | Mean | 288 | Records per | size | (mean; min; max) | compression | 289 | Data Set | | | ratio | 290 +-----------------+--------------+------------------+---------------+ 291 | 10 | 294 | 43.1; 39; 46 | 6.82 | 292 | 20 | 584 | 45.6; 41; 48 | 12.80 | 293 | 40 | 1164 | 49.7; 45; 52 | 23.42 | 294 | 60 | 1744 | 54.0; 50; 57 | 32.29 | 295 | 100 | 2904 | 63.4; 59; 66 | 45.80 | 296 +-----------------+--------------+------------------+---------------+ 298 Table 3: ISP Backbone Network: Compression Results 300 4.3. Packet Report Compression 302 As specified in [I-D.ietf-psamp-protocol], the IPFIX protocol can be 303 used to export PSAMP Packet Reports. In order to evaluate the 304 compression gain that can be achieved with Packet Records, we 305 compressed Data Sets containing IP packet header sections covering 306 the IP and transport layer headers. The Template definition is shown 307 in Table 4 below. The definition of the Information Elements can be 308 found in [I-D.ietf-psamp-info]. 310 +----------+------------------------+----------+ 311 | Field No | Information Element | Length | 312 +----------+------------------------+----------+ 313 | 1 | observationTimeSeconds | 4 | 314 | 2 | ipHeaderPacketSection | variable | 315 +----------+------------------------+----------+ 317 Table 4: Packet Report Template 319 120,000 packets were captured in the network of a research institute. 320 The resulting Packet Records were encapsulated in Data Sets of 321 different length. Table 5 shows the original and compressed lengths 322 of the Data Sets as well as the compression ratios. As can be seen, 323 the compression ratio stays below 2 even for a large number of Packet 324 Records per Data Set. Obviously, Packet Records are much less 325 compressible than Flow Records. The huge difference can be explained 326 by the fact that Flow Records usually contain packet header fields 327 where the observed values are very redundant. 329 +---------------+-------------------+-----------------+-------------+ 330 | Number of | Uncompressed size | Compressed size | Mean | 331 | Records per | (mean; min; max) | (mean; min; | compression | 332 | Data Set | | max) | ratio | 333 +---------------+-------------------+-----------------+-------------+ 334 | 10 | 405.5; 302; 574 | 318.3; 172; 437 | 1.27 | 335 | 20 | 807.0; 656; 1144 | 575.0; 341; 744 | 1.40 | 336 | 40 | 1610.1; 1324; | 1029.9; 615; | 1.56 | 337 | | 2260 | 1274 | | 338 | 60 | 2413.1; 2056; | 1451.9; 889; | 1.66 | 339 | | 3376 | 1771 | | 340 | 100 | 4019.3; 3512; | 2275.4; 1769; | 1.76 | 341 | | 5004 | 2675 | | 342 +---------------+-------------------+-----------------+-------------+ 344 Table 5: Packet Reports: Compression Results 346 5. Possible Realization of IPFIX Compression 348 In this section, we discuss different options that allow applying 349 compression methods to IPFIX traffic. At first, we describe two 350 solutions which are based on compression options provided by IPComp 351 and DTLS. As third and fourth option, we propose IPFIX-specific 352 solutions which do not depend on the underlying transport protocol, 353 but require extensions of the IPFIX protocol. 355 5.1. Compressed IPsec Tunnel 357 IP payload compression (IPComp) [RFC3173] enables the compression of 358 IP datagrams exchanged between a pair of communicating nodes. 359 Therefore, an IPComp association (IPCA) between the two nodes must be 360 established. DEFLATE [RFC2394] and Lempel-Ziv-Stac (LZS) [RFC2395] 361 are among the standardized compression methods. IPComp has been 362 conceived for compressing IP datagrams before sending them over an 363 encrypted tunnel. Dynamic negotiation of IPCAs has been standardized 364 as part of the Internet Key Exchange protocol (IKE) [RFC4306]. 366 If IPFIX traffic is transported over an IPsec tunnel, IPComp may be 367 used for compression. In this case, the compression is transparent 368 to both, Exporting Process and Collecting Process. 370 5.2. TLS/DTLS Compression 372 TLS [RFC4346] and DTLS [RFC4347] enable the negotiation and 373 deployment of a lossless compression method. Two compression methods 374 have been standardized for usage with TLS: DEFLATE [RFC3749] and 375 Lempel-Ziv-Stac (LZS) [RFC3943]. For DTLS, no compression methods 376 have been standardized, yet. 378 RFC 3749 [RFC3749] recommends the usage of stateful compression for 379 TLS, which means that a compression history across packets is 380 maintained to achieve higher compression ratios. DTLS has been 381 conceived for transport protocols that do not guarantee reliable, 382 sequenced packet delivery. In this case, only stateless per-packet 383 compression is possible. For example, DEFLATE and LZS could be 384 applied on a per-packet basis. 386 The IPFIX protocol specification [RFC5101] mandates the support of 387 DTLS if SCTP or UDP are used as transport protocol for IPFIX. 388 Similarly, if TCP is used as transport protocol, TLS must be 389 supported. Although no compression method has been standardized for 390 DTLS, DEFLATE [RFC1951] can be used for stateless compression of 391 individual SCTP messages or UDP datagrams. The utilization of DTLS 392 or TLS is not mandated by the IPFIX protocol. If DTLS or TLS are 393 employed, compression methods may be negotiated and deployed between 394 the Exporting Process and the Collecting Process. 396 5.3. Compressed IPFIX Messages 398 A compressed variant of the IPFIX Message format could be designed as 399 follows. The IPFIX Message header remains uncompressed and is 400 structured as defined in Section 3.1 of [RFC5101]. The message 401 payload following the IPFIX Message header is compressed using 402 DEFLATE as specified in [RFC1951]. Optionally, the ZLIB format 404 [RFC1950] could be used to enable the choice of alternative 405 compression methods and to protect the data integrity by a checksum. 406 In order to distinguish compressed IPFIX Messages from normal IPFIX 407 Messages, a new IPFIX Version Number must be used for compressed 408 IPFIX Messages, for example 0x000b. 410 Leaving the IPFIX Message header uncompressed facilitates the work of 411 both, Exporting Processes and Collecting Processes. The version 412 number and length field are required to decode the message correctly. 413 The Exporting Process does not know in advance how much time the 414 compression will require. Keeping the export time in the IPFIX 415 Message Header allows the Exporting Process to fill this field after 416 compressing the message payload. Finally, the uncompressed 417 Observation Domain ID allows the Collecting Process to classify IPFIX 418 Messages before decompressing the message payload. 420 5.4. Compressed Data Sets 422 Instead of compressing the entire payload of IPFIX Messages, it is 423 also possible to introduce a new Set type called Deflate Template 424 Set. Just like normal Template Sets, the Deflate Template Set is used 425 to carry Templates, namely Deflate Templates. The format of Deflate 426 Template Records is the same as the Template Record format specified 427 in Section 3.4.1 of [RFC5101]. However, the corresponding Data Sets 428 differ: starting with the first byte after the Set header, the 429 sequence of Deflate Data Records is compressed using DEFLATE 430 [RFC1951]. Again, the ZLIB format [RFC1950] could be used to enable 431 the choice of alternative compression methods and to protect the data 432 integrity by a checksum. The Set header remains uncompressed and 433 includes the length of the Set after compression. In order to 434 distinguish Deflate Template Sets from other Sets, a new Set ID value 435 must be specified (e.g., Set ID = 4). 437 Compression at the level of Data Sets is more flexible than the 438 compression of IPFIX Messages as described in Section 5.3 since it 439 allows exporting compressed and uncompressed Records within a single 440 IPFIX Message. On the other hand, the size of the compressed data 441 blocks is smaller, which usually results in lower compression ratios. 443 6. Security Considerations 445 The same security considerations as for the IPFIX protocol [RFC5101] 446 apply. 448 The protocol extensions discussed in Section 5.3 and Section 5.4 449 introduce additional security issues for the Collector. An attacker 450 may send forged compressed IPFIX Messages or Data Sets to the 451 Collector which require very large amount of memory after 452 decompression, leading to possible memory exhaustion. The 453 decompression of such data may also require enormous processing 454 resources, causing a temporary denial of service. The Collector must 455 implement a protection mechanism which ensures that the decompression 456 is interrupted if it spends large amount of memory or runtime. 458 7. IANA Considerations 460 The two compression solutions described in Section 5.3 and 461 Section 5.4 require the assignment of a new IPFIX Version Number or 462 IPFIX Set ID respectively. As specifed in [RFC5101], the 463 standardization of these solutions requires a Standards Action 464 [RFC2434]. 466 8. References 468 8.1. Normative References 470 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 471 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 472 October 1998. 474 [RFC5101] Claise, B., "Specification of the IP Flow Information 475 Export (IPFIX) Protocol for the Exchange of IP Traffic 476 Flow Information", RFC 5101, January 2008. 478 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 479 Meyer, "Information Model for IP Flow Information Export", 480 RFC 5102, January 2008. 482 [I-D.ietf-ipfix-file] 483 Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 484 Wagner, "An IPFIX-Based File Format", 485 draft-ietf-ipfix-file-01 (work in progress), 486 February 2008. 488 [I-D.ietf-psamp-protocol] 489 Claise, B., "Packet Sampling (PSAMP) Protocol 490 Specifications", draft-ietf-psamp-protocol-09 (work in 491 progress), December 2007. 493 [I-D.ietf-psamp-info] 494 Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 495 Carle, "Information Model for Packet Sampling Exports", 496 draft-ietf-psamp-info-08 (work in progress), 497 February 2008. 499 8.2. Informative References 501 [I-D.ietf-ipfix-reducing-redundancy] 502 Boschi, E., "Reducing Redundancy in IP Flow Information 503 Export (IPFIX) and Packet Sampling (PSAMP) Reports", 504 draft-ietf-ipfix-reducing-redundancy-04 (work in 505 progress), May 2007. 507 [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. 508 Aitken, "IPFIX Implementation Guidelines", RFC 5153, 509 April 2008. 511 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 512 "Requirements for IP Flow Information Export (IPFIX)", 513 RFC 3917, October 2004. 515 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 516 Specification version 3.3", RFC 1950, May 1996. 518 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 519 version 1.3", RFC 1951, May 1996. 521 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 522 Randers-Pehrson, "GZIP file format specification version 523 4.3", RFC 1952, May 1996. 525 [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", 526 RFC 2394, December 1998. 528 [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using 529 LZS", RFC 2395, December 1998. 531 [RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 532 Payload Compression Protocol (IPComp)", RFC 3173, 533 September 2001. 535 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 536 Compression Methods", RFC 3749, May 2004. 538 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 539 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 540 November 2004. 542 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 543 RFC 4306, December 2005. 545 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 546 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 548 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 549 Security", RFC 4347, April 2006. 551 [nFlow] Deri, L., "nFlow: Monitoring Flows on IPv4/v6 Networks", 552 TERENA Networking Conference 2004, June 2004. 554 [LOBSTER] "IST LOBSTER Project Homepage", 555 Homepage http://www.ist-lobster.org, 2008. 557 [PMI08] Politopoulos, P., Markatos, E., and S. Ioannidis, 558 "Evaluation of Compression of Remote Network Monitoring 559 Data Streams", IEEE Workshop on End-to-End Monitoring 560 Techniques and Services E2EMON 2008, April 2008. 562 [RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 563 August 2007. 565 [RFC4993] Newton, A., "A Lightweight UDP Transfer Protocol for the 566 Internet Registry Information Service", RFC 4993, 567 August 2007. 569 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 570 Liu, Z., and J. Rosenberg, "Signaling Compression 571 (SigComp)", RFC 3320, January 2003. 573 [RFC2083] Boutell, T., "PNG (Portable Network Graphics) 574 Specification Version 1.0", RFC 2083, March 1997. 576 Authors' Addresses 578 Gerhard Muenz 579 University of Tuebingen 580 Computer Networks and Internet 581 Sand 13 582 Tuebingen D-72076 583 DE 585 Phone: +49 7071 29-70534 586 Email: muenz@informatik.uni-tuebingen.de 587 URI: http://net.informatik.uni-tuebingen.de/~muenz 588 Lothar Braun 589 Technische Universitaet Muenchen 590 Network Architectures and Services, Institute for Informatics 591 Boltzmannstrasse 3 592 Garching D-85748 593 DE 595 Phone: +49 89 289-18010 596 Email: braun@net.in.tum.de 597 URI: http://www.net.in.tum.de/ 599 Full Copyright Statement 601 Copyright (C) The IETF Trust (2008). 603 This document is subject to the rights, licenses and restrictions 604 contained in BCP 78, and except as set forth therein, the authors 605 retain all their rights. 607 This document and the information contained herein are provided on an 608 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 609 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 610 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 611 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 612 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 613 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 615 Intellectual Property 617 The IETF takes no position regarding the validity or scope of any 618 Intellectual Property Rights or other rights that might be claimed to 619 pertain to the implementation or use of the technology described in 620 this document or the extent to which any license under such rights 621 might or might not be available; nor does it represent that it has 622 made any independent effort to identify any such rights. Information 623 on the procedures with respect to rights in RFC documents can be 624 found in BCP 78 and BCP 79. 626 Copies of IPR disclosures made to the IETF Secretariat and any 627 assurances of licenses to be made available, or the result of an 628 attempt made to obtain a general license or permission for the use of 629 such proprietary rights by implementers or users of this 630 specification can be obtained from the IETF on-line IPR repository at 631 http://www.ietf.org/ipr. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights that may cover technology that may be required to implement 636 this standard. Please address the information to the IETF at 637 ietf-ipr@ietf.org.