diff options
Diffstat (limited to 'rfc/rfc1979.txt')
| -rw-r--r-- | rfc/rfc1979.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/rfc/rfc1979.txt b/rfc/rfc1979.txt new file mode 100644 index 0000000..7a95cd3 --- /dev/null +++ b/rfc/rfc1979.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group J. Woods +Request for Comments: 1979 Proteon, Inc. +Category: Informational August 1996 + + + PPP Deflate Protocol + +Status of This Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + The PPP Compression Control Protocol [2] provides a method to + negotiate and utilize compression protocols over PPP encapsulated + links. + + This document describes the use of the PPP Deflate compression + protocol for compressing PPP encapsulated packets. + +Table of Contents + + 1. Introduction ...................................... 2 + 1.1 Licensing ................................... 2 + 2. PPP Deflate Packets ............................... 3 + 2.1 Packet Format ............................... 6 + 3. Configuration Option Format ....................... 8 + SECURITY CONSIDERATIONS .................................. 9 + REFERENCES ............................................... 9 + ACKNOWLEDGEMENTS ......................................... 9 + CHAIR'S ADDRESS .......................................... 10 + AUTHOR'S ADDRESS ......................................... 10 + + + + + + + + + + + + + + +Woods Informational [Page 1] + +RFC 1979 PPP Deflate August 1996 + + +1. Introduction + +The 'deflate' compression format[3], as used by the PKZIP and gzip +compressors and as embodied in the freely and widely distributed +zlib[4] library source code, has the following features: + + - an apparently unencumbered encoding and compression + algorithm, with an open and publically-available + specification. + + - low-overhead escape mechanism for incompressible data. The + PPP Deflate specification offers options to reduce that + overhead further. + + - heavily used for many years in networks, on modem and other + point-to-point links to transfer files for personal computers + and workstations. + + - easily achieves 2:1 compression on the Calgary corpus[5] + using less than 64KBytes of memory on both sender and + receive. + +1.1. Licensing + + The zlib source is widely and freely available, subject to the + following copyright: + + (C) 1995 Jean-Loup Gailly and Mark Adler + + This software is provided 'as-is', without any express or implied + warranty. In no event will the authors be held liable for any + damages arising from the use of this software. + + Permission is granted to anyone to use this software for any + purpose, including commercial applications, and to alter it and + redistribute it freely, subject to the following restrictions: + + 1. The origin of this software must not be misrepresented; you + must not claim that you wrote the original software. If you + use this software in a product, an acknowledgment in the + product documentation would be appreciated but is not + required. + + 2. Altered source versions must be plainly marked as such, and + must not be misrepresented as being the original software. + + + + + + +Woods Informational [Page 2] + +RFC 1979 PPP Deflate August 1996 + + + 3. This notice may not be removed or altered from any source + distribution. + + Jean-Loup Gailly Mark Adler + gzip@prep.ai.mit.edu madler@alumni.caltech.edu + + If you use the zlib library in a product, we would appreciate + *not* receiving lengthy legal documents to sign. The sources are + provided for free but without warranty of any kind. The library + has been entirely written by Jean-Loup Gailly and Mark Adler; it + does not include third-party code. + + The deflate format and compression algorithm are based on Lempel-Ziv + LZ77 compression; extensive research has been done by the GNU Project + and the Portable Network Graphics working group supporting its patent + free status. + +2. PPP Deflate Packets + + Before any PPP Deflate packets may be communicated, PPP must reach + the Network-Layer Protocol phase, and the CCP Control Protocol must + reach the Opened state. + + Exactly one PPP Deflate datagram is encapsulated in the PPP + Information field, where the PPP Protocol field contains 0xFD or + 0xFB. 0xFD is used when the PPP multilink protocol is not used or + "above" multilink. 0xFB is used "below" multilink, to compress + independently on individual links of a multilink bundle. + + The maximum length of the PPP Deflate datagram transmitted over a PPP + link is the same as the maximum length of the Information field of a + PPP encapsulated packet. + + Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF + and neither 0xFD nor 0xFB are compressed. Other PPP packets are + always sent uncompressed. Control packets are infrequent and should + not be compressed for robustness. + + Padding + + PPP Deflate packets require the previous negotiation of the Self- + Describing-Padding Configuration Option [6] if padding is added to + packets. If no padding is added, than Self-Describing-Padding is + not required. + + + + + + + +Woods Informational [Page 3] + +RFC 1979 PPP Deflate August 1996 + + + Reliability and Sequencing + + PPP Deflate requires the packets to be delivered in sequence. It + relies on Reset-Request and Reset-Ack LCP packets or on + renegotiation of the Compression Control Protocol [2] to indicate + loss of synchronization between the transmitter and receiver. The + LCP FCS detects corrupted packets and the normal mechanisms + discard them. Missing or out of order packets are detected by the + sequence number in each packet. The packet sequence number ought + to be checked before decoding the packet. + + Instead of transmitting a Reset-Request packet when detecting a + sequence error, the receiver MAY momentarily force CCP to drop out + of the Opened state by transmitting a new CCP Configure-Request. + This method is more expensive than using Reset-Requests. + + When the receiver first encounters an unexpected sequence number + it SHOULD send a Reset-Request LCP packet as defined in the + Compression Control Protocol. When the transmitter sends the + Reset-Ack or when the receiver receives a Reset-ACK, they must + reset the sequence number to zero, clear the compression + dictionary, and resume sending and receiving compressed packets. + The receiver MUST discard all compressed packets after detecting + an error and until it receives a Reset-Ack. This strategy can be + thought of as abandoning the transmission of one "file" and + starting the transmission of a new "file." + + The transmitter must clear its compression history and respond + with a Reset-Ack each time it receives a Reset-Request, because it + cannot know if previous Reset-Acks reached the receiver. The + receiver need not do anything to its history when it receives a + Reset-Ack, because the transmitter will simply not refer to any + prior history ('deflate' is a sliding-window compressor). + + When the link is busy, one decompression error is usually followed + by several more before the Reset-Ack can be received. It is + undesirable to transmit Reset-Requests more frequently than the + round-trip-time of the link, because redundant Reset-Requests + cause unnecessary compression dictionary clearing. The receiver + MAY transmit an additional Reset-Request each time it receives a + compressed or uncompressed packet until it finally receives a + Reset-Ack, but the receiver ought not transmit another Reset- + Request until the Reset-Ack for the previous one is late. The + receiver MUST transmit enough Reset-Request packets to ensure that + the transmitter receives at least one. For example, the receiver + might choose to not transmit another Reset-Request until after one + second (or, of course, a Reset-Ack has been received and + decompression resumed). + + + +Woods Informational [Page 4] + +RFC 1979 PPP Deflate August 1996 + + + Data Expansion + + 'Deflate', as used in this standard, expands incompressible data + by approximately 14-18 bytes (8 bytes worst-case at the 'deflate' + level, two further bytes for the 'deflate' end-of-block and the + zero-length synchronization block header, two bytes of sequence + number, and two bytes to account for adding the PPP Protocol Field + to the transmitted data unit). + + The BSD Compress draft proposal[7] describes an escape mechanism + for incompressible data that trades off a layering violation for + the irritating complications of variable and potentially + unpredictable effective MRU lengths. That direct escape mechanism + (and much of the text of its description) is used here as well. + + If an incompressible data packet does not fit within the MRU of + the link, the packet MUST be sent in its original form without CCP + encapsulation; PPP packets with significant data expansion that do + not exceed the MRU of the link SHOULD be sent in their original + form without CCP encapsulation. In both of these cases, the + transmitter must increment the sequence number, as future + encapsulated packets will depend on the correct reception of some + number of unencapsulated packets. + + When a PPP packet is received with PPP Protocol numbers in the + range 0x0000 to 0x3FFF, (except, of course, 0xFD and 0xFB) it is + assumed that the packet would have caused expansion. The packet + is locally added to the compression history. (Given the + definition of the 'deflate' format, a convenient method of doing + this is to locally "decompress" a stored-block header of the + appropriate length, followed by the actual data block; or the data + can simply be appended to the receiver's history, depending on + implementation details.) + + Sending incompressible packets in their native encapsulation + avoids maximum transmission unit complications. If uncompressed + packets could be larger than their native form, then it would be + necessary for the upper layers of an implementation to treat the + PPP link as if it had a smaller MTU, to ensure that compressed + incompressible packets are never larger than the negotiated PPP + MTU. + + Using native encapsulation for incompressible packets complicates + the implementation. The transmitter and the receiver must start + putting information into the compression dictionary starting with + the same packets, without relying upon seeing a compressed packet + for synchronization. The first few packets after clearing the + dictionary are usually incompressible, and so are likely to sent + + + +Woods Informational [Page 5] + +RFC 1979 PPP Deflate August 1996 + + + in their native encapsulation, just like packets before + compression is turned on. If CCP or LCP packets are handled + separately from Network-Layer packets (e.g. a "daemon" for control + packets and "kernel code" for data packets), care must be taken to + ensure that the transmitter synchronizes clearing the dictionary + with the transmission of the configure-ACK or Reset-Ack that + starts compression, and the receiver must similarly ensure that + its dictionary is cleared before it processes the next packet. + +2.1. Packet Format + + A summary of the PPP Deflate packet format is shown below. + + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP Protocol | Sequence | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+-+-+-+-+ + + + PPP Protocol + + The PPP Protocol field is described in the Point-to-Point Protocol + Encapsulation [1]. + + When the PPP Deflate compression protocol is successfully + negotiated by the PPP Compression Control Protocol [2], the value + of the protocol field is 0xFD or 0xFB. This value MAY be + compressed when Protocol-Field-Compression is negotiated. + + Sequence + + The sequence number is sent most significant octet first. It + starts at 0 when the dictionary is cleared, and is incremented by + 1 for each packet, including uncompressed packets. The sequence + number after 65535 is zero. In other words, the sequence number + "wraps" in the usual way. + + The sequence number ensures that lost or out of order packets do + not cause the compression databases of the peers to become + unsynchronized. When an unexpected sequence number is + encountered, the dictionaries must be resynchronized with a CCP + Reset-Request or Configure-Request. The packet sequence number + can be checked before a compressed packet is decoded. + + + +Woods Informational [Page 6] + +RFC 1979 PPP Deflate August 1996 + + + Data + + The compressed PPP encapsulated packet, consisting of the Protocol + and Data fields of the original, uncompressed packet follows. + + The Protocol field compression MUST be applied to the protocol + field in the original packet before the sequence number is + computed or the entire packet is compressed, regardless of whether + the PPP protocol field compression has been negotiated. Thus, if + the original protocol number was less than 0x100, it must be + compressed to a single byte. + + The basic format of the compressed data is precisely described by + the 'Deflate' Compressed Data Format Specification[3]. Each + transmitted packet must begin at a 'deflate' block boundary, to + ensure synchronization when incompressible data resets the + transmitter's state; to ensure this, each transmitted packet must + be terminated with a zero-length 'deflate' non-compressed block + (BTYPE of 00). This means that the last four bytes of the + compressed format must be 0x00 0x00 0xFF 0xFF. These bytes MUST + be removed before transmission; the receiver can reinsert them if + required by the implementation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woods Informational [Page 7] + +RFC 1979 PPP Deflate August 1996 + + +3. Configuration Option Format + + + Description + + The CCP PPP Deflate Configuration Option negotiates the use of PPP + Deflate on the link. By default or ultimate disagreement, no + compression is used. + + A summary of the PPP Deflate Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length |Window | Method| MBZ |Chk| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 26 for PPP Deflate. + + Length + + 3 + + Window + + Represents the maximum window size the decompressor is willing to + allocate; expressed as the base-2 logarithm of the LZ77 window + size, minus 8. 'Deflate' compliant decompressors must be willing + to accept the maximum 32KB window size, represented by a value of + 7. A 'deflate' compliant compressor is at liberty to use a + reduced window size, so a PPP Deflate compressor MUST either honor + the restriction requested or reject the option. + + Method + + Must be the binary number 1000. Represents the 'zlib' Compression + Method identifier of '8' for 'deflate' compression with up to 32K + window size. + + MBZ + + Must be all 0 bits. + + + + + +Woods Informational [Page 8] + +RFC 1979 PPP Deflate August 1996 + + + Chk + + Must be 00 to specify sequence number check method. + +Security Considerations + + Security issues are not discussed in this memo. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [2] Rand, D., "The PPP Compression Control Protocol (CCP)", + RFC 1962, June 1996. + + [3] Deutsch, L.P., "'Deflate' Compressed Data Format + Specification", draft available in + ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc. + + [4] Gailly, J.-L., "Zlib 0.95 beta". + + [5] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression", + Prentice_Hall, Englewood Cliffs NJ, 1990. The compression + corpus itself can be found in ftp.uu.net:/pub/archiving/zip/. + + [6] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994. + + [7] Schryver, V., "PPP BSD Compression Protocol", RFC 1977, + August 1996. + +Acknowledgments + + William Simpson provided the very valuable idea of not using any + additional header bytes for incompressible packets. + + + + + + + + + + + + + + + + +Woods Informational [Page 9] + +RFC 1979 PPP Deflate August 1996 + + +Chair's Address + + The working group can be contacted via the current chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive, Suite 101 + Columbus, Ohio 43221 + + EMail: karl@ascend.com + +Author's Address + + Questions about this memo can also be directed to: + + John Woods + Proteon, Inc. + 9 Technology Drive + Westborough MA 01581-1799 + + (508) 898-2800 ext. 2651 + EMail: jfw@funhouse.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woods Informational [Page 10] + |