idnits 2.17.1 draft-ietf-ippcp-lzs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC-1967], [Thomas]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 137 has weird spacing: '...pansion produ...' -- 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 29, 1997) is 9768 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) == Unused Reference: 'AH' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'DOI' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'ESP' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC-1700' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC-1883' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC-1962' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC-2003' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'Shacham' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'Thayer' is defined on line 322, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Calgary' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-02 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'DOI') == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-00 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') -- Possible downref: Non-RFC (?) normative reference: ref. 'LZ1' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Downref: Normative reference to an Informational RFC: RFC 1967 == Outdated reference: A later version (-05) exists of draft-ietf-ippcp-protocol-00 == Outdated reference: A later version (-04) exists of draft-thayer-seccomp-01 -- Possible downref: Normative reference to a draft: ref. 'Thayer' -- Possible downref: Normative reference to a draft: ref. 'Thomas' Summary: 15 errors (**), 0 flaws (~~), 20 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Monsour 2 Expires in six months Hi/fn, Inc. 3 July 29, 1997 5 IP Payload Compression Using LZS 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet-Drafts draft documents are valid for a maximum of six months 16 and may be updated, replaced, or obsolete by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Distribution of this memo is unlimited. 28 It is intended that a future version of this draft be submitted to the 29 IESG for publication as an Informational RFC. 31 Abstract 33 This document describes a IP compression method based on the LZS 34 compression algorithm. This document defines the application of the 35 LZS algorithm to the IP Payload Compression Protocol [Thomas]. 36 [Thomas] defines a method for applying lossless compression to the 37 payloads of Internet Protocol datagrams. 39 Acknowledgments 41 The LZS details presented here are similar to those in PPP LZS-DCP 42 Compression Protocol (LZS-DCP)" [RFC-1967]. 44 The author wishes to thank the participants of the IPPCP working group 45 mailing list whose discussion is currently active and is working to 46 generate the protocol specification for integrating compression with 47 IP. 49 Table of Contents 50 1. Introduction...................................................2 51 1.1 General....................................................2 52 1.2 Background of LZS Compression..............................2 53 1.3 Licensing..................................................3 54 1.4 Specification of Requirements..............................3 55 2. Compression Process............................................3 56 2.1 Compression History........................................3 57 2.2 Anti-expansion of Payload Data.............................3 58 2.3 Format of Compressed Datagram Payload......................4 59 2.4 Compression Encoding Format................................5 60 2.5 Padding....................................................6 61 3. Decompression Process..........................................6 62 4. Security Considerations........................................6 63 5. References.....................................................6 64 6. Authors Addresses..............................................8 65 7. Appendix: Compression Efficiency versus Datagram Size..........8 67 1. Introduction 69 1.1 General 71 This document is a submission to the IETF IP Payload Compression 72 Protocol (IPPCP) Working Group. Comments are solicited and should be 73 addressed to the working group mailing list (ippcp@external.cisco.com) 74 or to the editor. 76 This document specifies the application of LZS compression, a lossless 77 compression algorithm, to IP datagram payloads. It is to be used in 78 conjunction with the IP Payload Compression Protocol which, at this 79 writing, is under development by the IP Payload Compression Protocol 80 working group. 82 1.2 Background of LZS Compression 84 Starting with a sliding window compression history, similar to LZ1 85 [LZ1], Hi/fn developed a new, enhanced compression algorithm 86 identified as LZS. The LZS algorithm is optimized to compress all file 87 types as efficiently as possible. Even string matches as short as two 88 octets are effectively compressed. 90 The LZS algorithm uses a sliding window of 2,048 bytes. During 91 compression, redundant sequences of data are replaced with tokens that 92 represent those sequences. During decompression, the original 93 sequences are substituted for the tokens in such a way that the 94 original data is exactly recovered. LZS differs from lossy compression 95 algorithms, such as those often used for video compression, that do 96 not exactly reproduce the original data. 98 The details of LZS compression can be found in [ANSI94]. 100 The efficiency of the LZS algorithm depends on the degree of 101 redundancy in the original data. A typical compression ratio is 2:1. 102 LZS achieves a compression ratio of 2.34:1 on the University of 103 Calgary Text Compression Corpus [Calgary]. 105 1.3 Licensing 107 Hi/fn, Inc. holds patents on the LZS algorithm. Licenses for a 108 reference implementation are available for use in IPPCP, IPSec, TLS 109 and PPP applications at no cost. Source and object licenses are 110 available on a non-discriminatory basis. Hardware implementations are 111 also available. For more information, contact Hi/fn at the address 112 listed with the author's address. 114 1.4 Specification of Requirements 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC2119 [RFC-2119]. 120 2. Compression Process 122 2.1 Compression History 124 The sender MUST reset the compression history prior to processing each 125 datagram's payload. This ensures that each datagram's payload can be 126 decompressed independently of any other, as is needed when datagrams 127 are received out of order. 129 The sender MUST flush the compressor each time it transmits a 130 compressed datagram. Flushing means that all data going into the 131 compressor is included in the output, i.e., no data is held back in 132 the hope of achieving better compression. Flushing is necessary to 133 prevent a datagram's data from spilling over into a later datagram. 135 2.2 Anti-expansion of Payload Data 137 The maximum expansion produced by the LZS algorithm is 12.5%. 139 If the size of a compressed IP datagram, including whatever overhead 140 is included to define the compression protocol, is not smaller than 141 the size of the original IP datagram, the IP datagram MUST be sent in 142 the original non-compressed form. This policy ensures saving the 143 decompression processing cycles and avoiding incurring IP datagram 144 fragmentation when the expanded datagram is larger than the MTU. 146 Small IP datagrams are more likely to expand as a result of 147 compression. Therefore, a numeric threshold SHOULD be applied before 148 compression, where IP datagrams of size smaller than the threshold are 149 sent in the original form without attempting compression. The numeric 150 threshold is implementation dependent. 152 An IP datagram with payload, which has been previously compressed, 153 tends not to compress any further. Such previously compressed payload 154 may be the result of external processes, such as compression applied 155 by an upper layer in the communication stack, or by an off-line 156 compression utility. An adaptive algorithm SHOULD be implemented in 157 order to avoid the performance penalty of futile compression attempts. 158 Such as adaptive algorithm is implementation dependent and independent 159 of compression method. 161 2.3 Format of Compressed Datagram Payload 163 The following is an example datagram that results when using LZS as 164 the compression algorithm for the IP Payload Control Protocol. Note 165 that the IP header has been omitted for clarity. 167 0 1 2 3 168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Compression Parameters Index (CPI) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |C| Reserved | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | | 175 ~ Payload Data (variable) ~ 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Compression Parameters Index (CPI) 181 The Compression Parameters Index (CPI) is a 32-bit pseudo-random 182 value identifying the association for this datagram. The details of 183 its use can be found in [Thomas]. 185 C 186 This one-bit field, when one, indicates that the datagram payload is 187 compressed; a value of zero indicates that the datagram payload is 188 not compressed. 190 Reserved 192 This 31-bit field is reserved for future use and MUST be zeroed by 193 the sender. It SHOULD be ignored by the receiver. 195 Payload Data 197 This variable-length field contains the optionally compressed 198 datagram payload. 200 2.4 Compression Encoding Format 202 The input to the payload compression algorithm is an IP datagram 203 payload. The output of the algorithm is a new (and hopefully smaller) 204 payload. The output payload contains the input payload's data in 205 either compressed or uncompressed format. The input and output 206 payloads are each an integral number of bytes in length. 208 If the uncompressed form is used, the output payload is identical to 209 the input payload. If the compressed form is used, the output payload 210 as defined in section 3.2 of [ANSI94], and is repeated here for 211 informational purposes ONLY. 213 := [] 214 := 0 | 1 215 := (8-bit byte) 216 := 218 := 1 | (7-bit offset) 219 0 (11-bit offset) 220 := 110000000 222 := 1 | 0 224 := 225 00 = 2 1111 0110 = 14 226 01 = 3 1111 0111 = 15 227 10 = 4 1111 1000 = 16 228 1100 = 5 1111 1001 = 17 229 1101 = 6 1111 1010 = 18 230 1110 = 7 1111 1011 = 19 231 1111 0000 = 8 1111 1100 = 20 232 1111 0001 = 9 1111 1101 = 21 233 1111 0010 = 10 1111 1110 = 22 234 1111 0011 = 11 1111 1111 0000 = 23 235 1111 0100 = 12 1111 1111 0001 = 24 236 1111 0101 = 13 ... 238 2.5 Padding 240 A datagram payload compressed using LZS always ends with the last 241 compressed data byte (also known as the ), which is used 242 to disambiguate padding. This allows trailing bits as well as bytes 243 to be considered padding. 245 3. Decompression Process 247 If the C bit of the received datagram is a one (i.e., indicating the 248 datagram is compressed), the receiver MUST reset the compression 249 history prior to processing the datagram. This ensures that each 250 datagram can be decompressed independently of any other, as is needed 251 when datagrams are received out of order. Following the reset of the 252 compression history, the receiver decompresses the Payload Data field 253 according to the encoding specified in section 3.2 of [ANSI94]. 255 If the C bit of the received datagram is zero, the receiver needs to 256 perform no decompression processing and the Payload Data field of the 257 datagram is ready for processing by the next protocol layer. 259 4. Security Considerations 261 This memo discusses the use of lossless compression technology in the 262 Internet Protocol. This can include use of IP Security. The proposed 263 use of compression within this protocol is not believed to have an 264 effect on the underlying security functionality provide by the 265 protocol; i.e., the use of compression is not known to degrade or 266 alter the nature of the underlying security architecture or the 267 encryption technologies used to implement it. 269 The use of compression does change the length of ESP payloads, in a 270 manner that depends on the data prior to encryption. Thus, the use of 271 compression may have an effect on the ability of an eavesdropper to 272 glean information by analyzing the length of transmitted packets. 274 5. References 276 [AH] Kent, S. and Atkinson, R., "IP Authentication Header", draft- 277 ietf-ipsec-auth-header-01.txt, Work in Progress, July 1997. 279 [ANSI94] American National Standards Institute, Inc., "Data 280 Compression Method for Information Systems," ANSI X3.241-1994, August 281 1994. 283 [Calgary] Text Compression Corpus, University of Calgary, available 284 at ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus. 286 [DOI] Piper, D., "The Internet IP Security Domain of Interpretation 287 for ISAKMP", draft-ietf-ipsec-ipsec-doi-02.txt, Work in Progress, 288 February 1997. 290 [ESP] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload", 291 draft-ietf-ipsec-esp-v2-00.txt, Work in Progress, July 1997. 293 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 294 "Internet Security Association and Key Management Protocol (ISAKMP)", 295 draft-ietf-ipsec-isakmp-08.txt, Work in Progress, July 1997. 297 [LZ1] Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential 298 Data Compression", IEEE Transactions On Information Theory, Vol. IT- 299 23, No. 3, May 1977. 301 [RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, 302 October 1994. 304 [RFC-1883] Deering, S., Hinden, R., "Internet Protocol, Version 6 305 (IPv6) Specification", RFC 1883, April 1996. 307 [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 308 RFC-1962, June 1996. 310 [RFC-1967] K. Schneider, R. Friend, "PPP LZS-DCP Compression Protocol 311 (LZS-DCP)", RFC-1967, August, 1996. 313 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 314 October 1996. 316 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", RFC 2119, March 1997. 319 [Shacham] Shacham, A., "IP Payload Compression Protocol (IPComp)", 320 draft-ietf-ippcp-protocol-00.txt, Work in Progress, July 1997. 322 [Thayer] Thayer, R., "Compression Payload for Use with IP Security", 323 draft-thayer-seccomp-01.txt, Work in Progress, March, 1997. 325 [Thomas] Thomas, M., "The Compressed Payload Header", draft-thomas- 326 ippcp-compression-00.txt, Work in Progress, July 1997. 328 6. Authors Addresses 330 Robert Monsour 331 Hi/fn Inc. 332 5973 Avenida Encinas 333 Suite 110 334 Carlsbad, CA 92008 335 Email: rmonsour@hifn.com 337 7. Appendix: Compression Efficiency versus Datagram Size 339 The following table offers some guidance on the compression efficiency 340 that can be achieved as a function of datagram size. Each entry in 341 the table shows the compression ratio that was achieved when LZS was 342 applied to a test file using datagrams of a specified size. 344 The test file was the University of Calgary Text Compression Corpus 345 [Calgary]. The length of the file prior to compression was 3,278,000 346 bytes. When the entire file was compressed as a single payload, a 347 compression ratio of 2.34 resulted. 349 Datagram size,| 350 bytes | 64 128 256 512 1024 2048 4096 8192 16384 351 --------------|---------------------------------------------------- 352 Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14 353 ratio |