Network Working Group D Rand Internet Draft Novell Expires in six months October 1993 The PPP Compression Control Protocol (CCP) draft-ieft-pppext-compression-01.txt Status of this Memo This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data compression over PPP links, and describes the use of several such data compression protocols. Dave Rand expires in six months [Page i] DRAFT PPP Compression October 1993 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention). Dave Rand expires in six months [Page 1] DRAFT PPP Compression October 1993 2. A PPP Control Protocol (NCP) for Compression The Compression Control Protocol (CCP) is responsible for configuring, enabling, and disabling data compression algorithms on both ends of the point-to-point link. It is also used to signal a failure of the compression/decompression mechanism in a reliable manner. CCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). CCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. CCP packets received before this phase is reached should be silently discarded. The Compression Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one CCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex (0xFD) (Compression Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Timeouts CCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types CCP has a distinct set of Configuration Options, which are defined below. 2.1. Sending Compressed Datagrams Before any compressed packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the Compression Control Protocol must reach the Opened state. One or more compressed packets are encapsulated in the Information Dave Rand expires in six months [Page 2] DRAFT PPP Compression October 1993 field of PPP Data Link Layer frames. Each of the compression types may use a different mechanism to indicate the inclusion of more than one uncompressed frame in a single PPP Data Link Layer frame. The Protocol Identifier of the compressed datagram indicates that the frame is compressed, but not the algorithm with which it was compressed. Only one algorithm may be in use at time, and that is negotiated prior to the first compressed frame being transmitted. The maximum length of a compressed packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger datagrams (presumably the result of the compression algorithm increasing the size of the message in some cases) may be sent uncompressed, using its standard form, or may be sent in multiple datagrams, if the compression algorithm supports it. Dave Rand expires in six months [Page 3] DRAFT PPP Compression October 1993 3. CCP Configuration Options CCP Configuration Options allow negotiation of compression algorithms and their parameters. CCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. Configuration Options, in this protocol, indicate algorithms that the receiver is willing or able to use to decompress data sent by the sender. As a result, it is to be expected that systems will offer to accept several differing sets of algorithms, and negotiate down to one that will indeed be used. There is the possibility of not being able to agree on a compression algorithm. In that case, no compression will be used, and the link will come up without compression. If LAPB has been separately negotiated, then LAPB will be used (unless it is re-negotiated off). We expect many vendors to want to use proprietary compression algorithms, and have made a mechanism available to negotiate these without encumbering the Internet Assigned Number Authority with proprietary number requests. If none of the protocols are not recognized, a Configure-Reject MAY be sent with the entire, unmodified Configure-Request. The original transmitter of the Configure-Request, which was hoping to negotiate a compression of future network data packets sent to it, SHOULD interpret such a Configure-Reject as indicating that none of the proposed compression protocols are possible. If any of the protocols are recognized but not acceptable due to local options in the request (or optional parameters not in the request), a Configure-NAK MUST be sent with the local options modified appropriately. The Configure-NAK SHOULD contain only those protocols that might be acceptable. Other protocols which are unacceptable, whether because unrecognized or for other reasons, MUST NOT be listed in the option in the Configure-NAK. A new Configure-Request MAY then be sent with the options adjusted as specified in the Configure-Nak. The most up-to-date values of the CCP Option Type field are specified in the most recent "Assigned Numbers" RFC [6]. Current values are assigned as follows: CCP Option Meaning 1 Compression type negotiation (common) 2 Compression type negotiation (OUI/proprietary) Dave Rand expires in six months [Page 4] DRAFT PPP Compression October 1993 3.1. Compression Type Negotiation Option (common) Description This Configuration Option provides a way to negotiate the use of a standard compression algorithm. As of this writing, several compression algorithms are specified (see appendix). By default, compression is not enabled. 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 | Comp. Types | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length >= 3 Comp. Types (Compression Types) The compression types field lists the common compression algorithms that the are available. They must be listed in the order of desirability for this particular link. Each compression type is followed with a length, which may be 0. The length indicates the number of octets of compression-specific negotiation information, which may include items such as dictionary size, maximum string length and number of dictionaries. The receiver will process the compression types field from left to right, selecting the first protocol that matches the receiver's capability. If an acceptable compression protocol with acceptable options is encountered, the Configure-Request MUST be ACK'ed. The ACK MUST list only this acceptable protocol If no completely acceptable protocol is found, but one or more protocols are understood, but some or all of the compression negotiation options are not acceptable, these may be modified and sent back in a Configure-Nak. If none of the protocols are understood or no acceptable alternate Dave Rand expires in six months [Page 5] DRAFT PPP Compression October 1993 compression negotiation options are possible, a Configure-Reject MUST be transmitted. This Configure-Reject MUST be identical to the original Configure-Request as required by PPP protocols. Implementation of any particular compression algorithm IS NOT guaranteed. If all protocols the sender implements are Configure-Rejected by the receiver, then no compression is enabled. Default No compression protocol enabled. Dave Rand expires in six months [Page 6] DRAFT PPP Compression October 1993 3.2. Compression Type Negotiation Option (OUI/Proprietary) Description This Configuration Option provides a way to negotiate the use of a proprietary compression protocol. By default, such compression is not enabled. Since the first matching compression will be used, it is recommended that any known OUI compression options be transmitted first, before the common options are used. Before accepting this option, the implementation must verify that the Organizationally Unique Identifier identifies a proprietary algorithm that the implementation can decompress, and that any vendor specific negotiation options are fully understood. If no OUIs are supported by an implementation, a Configure-Reject may be sent back for any type 2 Compression Type Negotiation Option. A summary of the Proprietary Compression Algorithm 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 | OUI MS octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI remaining octects | Length | options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length >= 3 IEEE OUI The vendor's IEEE Organizationally Unique Identifier (OUI), which is the most significant three octets of an Ethernet Physical Address, assigned to the vendor by IEEE 802. This identifies the option as being proprietary to the indicated vendor. Multiple proprietary compression types may be offered, each with a different OUI, by sending them out after a REJect for any previous OUI has been received by the sender. When a supported vendor- specific proprietary compression is seen, and the option field is valid, a Configure-Ack may be sent to indicate acceptance of this Dave Rand expires in six months [Page 7] DRAFT PPP Compression October 1993 compression type. Multiple vendor-specific proprietary compression types may be implemented by the option field, which may contain algorithm selection information, negotiated options such as dictionary size, or any other information required. If the information in the option field is unrecognized, a Configure-Reject MUST be sent. If the information in the option field is recognized, but certain value(s) are unavailable, a Configure-Nak MAY be sent with the appropriate values modified. Any unrecognized proprietary compression configure request MUST have a Configure-Reject sent back. Length The Length field specifies the number of octects of OUI-specific negotiation information, in free format. It may be followed by 0 to 255 octets of negotiation information. options The options field is zero or more octets and contains additional data as determined by the vendor's compression protocol. Default No proprietary compression protocol enabled. Dave Rand expires in six months [Page 8] DRAFT PPP Compression October 1993 A. Common compression number identification The following numbers for common compression option use have been defined. Compression ID Algorithm specified 1 Predictor type 1 2 Predictor type 2 3 Puddle Jumper 16 Hewlett-Packard PPC 17 Stac Electronics LZS 18 Microsoft PPC 19 Gandalf FZA 20 V.42bis compression 21 UNIX LZW Compress IDs 4-15 are reserved for other freely-available implementations of compression algorithms. Dave Rand expires in six months [Page 9] DRAFT PPP Compression October 1993 B. Common compression algorithm definitions A compression algorithm that is available without license fees is the predictor algorithm, defined below. Note that although care has been taken to ensure that the following code does not infringe any patents, there is no assurance that it is not covered by a patent. Use the following code at your own risk. B.1. Predictor algorithm Predictor works by filling a guess table with values, based on the hash of the previous characters seen. Since we are either emitting the source data, or depending on the guess table, we add a flag bit for every byte of input, telling the decompressor if it should retrieve the byte from the compressed data stream, or the guess table. Blocking the input into groups of 8 characters means that we don't have to bit-insert the compressed output - a flag byte preceeds every 8 bytes of compressed data. Each bit of the flag byte corresponds to one byte of reconstructed data. Take the source file: 000000 4141 4141 4141 410a 4141 4141 4141 410a AAAAAAA.AAAAAAA. 000010 4141 4141 4141 410a 4141 4141 4141 410a AAAAAAA.AAAAAAA. 000020 4142 4142 4142 410a 4241 4241 4241 420a ABABABA.BABABAB. 000030 7878 7878 7878 780a xxxxxxx. Compressing the above data yields the following: 000000 6041 4141 4141 0a60 4141 4141 410a 6f41 `AAAAA.`AAAAA.oA 000010 0a6f 410a 4142 4142 4142 0a60 4241 4241 .oA.ABABAB.`BABA 000020 420a 6078 7878 7878 0a B.`xxxxx. Reading the above data says: flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6. Reconstructed data is: 0 1 2 3 4 5 6 7 File: A A A A A Guess table: A A flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6. Reconstructed data is: 0 1 2 3 4 5 6 7 File: A A A A A Guess table: A A flag = 0x6f - 6 bytes in this block were guessed correctly, 0-3, 5 and 6. Reconstructed data is: 0 1 2 3 4 5 6 7 File: A Guess table: A A A A A A flag = 0x6f - 6 bytes in this block were guessed correctly, 0-3, 5 and 6. Reconstructed data is: 0 1 2 3 4 5 6 7 Dave Rand expires in six months [Page 10] DRAFT PPP Compression October 1993 File: A Guess table: A A A A A A flag = 0x41 - 2 bytes in this block were guessed correctly, 0 and 6. Reconstructed data is: 0 1 2 3 4 5 6 7 File: B A B A B Guess table: A A flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6. Reconstructed data is: 0 1 2 3 4 5 6 7 File: B A B A B Guess table: A B flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6 Reconstructed data is: 0 1 2 3 4 5 6 7 File: x x x x x Guess table: x x And now, on to the source - note that it has been modified to work with a split block. If your data stream can't be split within a block (eg, compressing packets), then the code dealing with "final", and the memcpy are not required. You can detect this situation (or errors, for that matter) by observing that the flag byte indicates that more data is required from the compressed data stream, but you are out of data (len in decompress is <= 0). It *is* ok if len == 0, and flags indicate guess table usage. #include #ifdef __STDC__ #include #endif #include /* * pred.c -- Test program for Dave Rand's rendition of the * predictor algorithm * Updated by: iand@labtam.labtam.oz.au (Ian Donaldson) * Updated by: Carsten Bormann * Original : Dave Rand / */ /* The following hash code is the heart of the algorithm: * It builds a sliding hash sum of the previous 3-and-a-bit characters * which will be used to index the guess table. * A better hash function would result in additional compression, * at the expense of time. */ #define HASH(x) Hash = (Hash << 4) ^ (x) static unsigned short int Hash; static unsigned char GuessTable[65536]; Dave Rand expires in six months [Page 11] DRAFT PPP Compression October 1993 static int compress(source, dest, len) unsigned char *source, *dest; int len; { int i, bitmask; unsigned char *flagdest, flags, *orgdest; orgdest = dest; while (len) { flagdest = dest++; flags = 0; /* All guess wrong initially */ for (bitmask=1, i=0; i < 8 && len; i++, bitmask <<= 1) { if (GuessTable[Hash] == *source) { flags |= bitmask; /* Guess was right - don't output */ } else { GuessTable[Hash] = *source; *dest++ = *source; /* Guess wrong, output char */ } HASH(*source++);len--; } *flagdest = flags; } return(dest - orgdest); } static int decompress(source, dest, lenp, final) unsigned char *source, *dest; int *lenp, final; { int i, bitmask; unsigned char flags, *orgdest; int len = *lenp; orgdest = dest; while (len >= 9) { flags = *source++; for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) { if (flags & bitmask) { *dest = GuessTable[Hash]; /* Guess correct */ } else { GuessTable[Hash] = *source; /* Guess wrong */ *dest = *source++; /* Read from source */ len--; } HASH(*dest++); } len--; Dave Rand expires in six months [Page 12] DRAFT PPP Compression October 1993 } while (final && len) { flags = *source++; len--; for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) { if (flags & bitmask) { *dest = GuessTable[Hash]; /* Guess correct */ } else { if (!len) break; /* we seem to be really done -- cabo */ GuessTable[Hash] = *source; /* Guess wrong */ *dest = *source++; /* Read from source */ len--; } HASH(*dest++); } } *lenp = len; return(dest - orgdest); } #define SIZ1 8192 static void compress_file(f) FILE *f; { char bufp[SIZ1]; char bufc[SIZ1/8*9+9]; int len1, len2; while ((len1 = fread(bufp, 1, SIZ1, f)) > 0) { len2 = compress((unsigned char *)bufp, (unsigned char *)bufc, len1); (void) fwrite(bufc, 1, len2, stdout); } } static void decompress_file(f) FILE *f; { char bufp[SIZ1+9]; char bufc[SIZ1*9+9]; int len1, len2, len3; len1 = 0; while ((len3 = fread(bufp+len1, 1, SIZ1, f)) > 0) { len1 += len3; len3 = len1; len2 = decompress((unsigned char *)bufp, (unsigned char *)bufc, &len1, 0); (void) fwrite(bufc, 1, len2, stdout); (void) memcpy(bufp, bufp+len3-len1, len1); } Dave Rand expires in six months [Page 13] DRAFT PPP Compression October 1993 len2 = decompress((unsigned char *)bufp, (unsigned char *)bufc, &len1, 1); (void) fwrite(bufc, 1, len2, stdout); } int main(ac, av) int ac; char** av; { char **p = av+1; int dflag = 0; for (; --ac > 0; p++) { if (!strcmp(*p, "-d")) dflag = 1; else if (!strcmp(*p, "-")) (dflag?decompress_file:compress_file)(stdin); else { FILE *f = fopen(*p, "r"); if (!f) { perror(*p); exit(1); } (dflag?decompress_file:compress_file)(f); (void) fclose(f); } } return(0); } B.2. Encapsulation for Predictor type 1 The correct encapsulation for type 1 compression is the protocol type, 1 bit indicating if the data is compressed or not, 15 bits of the uncompressed data length in octets, compressed data, and uncompressed CRC-16 of the two octets of unsigned length in network byte order, followed by the original, uncompressed data packet. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCP Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| Uncompressed length (octets)| * is compressed flag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 means data is compressed | Compressed data... | 0 means data is not compressed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC - 16 | Dave Rand expires in six months [Page 14] DRAFT PPP Compression October 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The CCP Protocol Identifier that starts the packet is always 0xfd. If PPP Protocol field compression has not be negotiated, it MUST be a 16-bit field. The Compressed data is the Protocol Identifier and the Info fields of the original PPP packet described in [1], but not the Address, Control, FCS, or Flag. The CCP Protocol field MAY be compressed as described in [1], regardless of whether the Protocol field of the CCP Protocol Identifier is compressed or whether PPP Protocol field compression has been negotiated. It is not required that any of the fields land on an even word boundary - the compressed data may be of any length. If during the decode procedure, the CRC-16 does not match the decoded frame, it means that the compress or decompress process has become desyncronized. This will happen as a result of a frame being lost in transit if LAPB is not used. In this case, a new configure- request must be sent, and the CCP will drop out of the open state. Upon receipt of the configure-ack, the predictor tables are cleared to zero, and compression can be resumed without data loss. B.3. Encapsulation for Predictor type 2 The correct encapsulation for type 2 compression is the protocol type, followed by the data stream. Within the data stream is the current frame length (uncompressed), compressed data, and uncompressed CRC-16 of the two octets of unsigned length in network byte order, followed by the original, uncompressed data. The data stream may be broken at any convenient place for encapsulation purposes. With type 2 encapsulation, LAPB is almost essential for correct delivery. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCP Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| Uncompressed length (octets)| * is compressed flag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 means data is compressed | Compressed data... | 0 means data is not compressed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| Uncompressed length (octets)| * is compressed flag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Dave Rand expires in six months [Page 15] DRAFT PPP Compression October 1993 The CCP Protocol Identifier that starts the packet is always 0xfd. If PPP Protocol field compression has not be negotiated, it MUST be a 16-bit field. The Compressed data is the Protocol Identifier and the Info fields of the original PPP packet described in [1], but not the Address, Control, FCS, or Flag. The CCP Protocol field MAY be compressed as described in [1], regardless of whether the Protocol field of the CCP Protocol Identifier is compressed or whether PPP Protocol field compression It is not required that any field land on an even word boundary - the compressed data may be of any length. If during the decode procedure, the CRC-16 does not match the decoded frame, it means that the compress or decompress process has become desyncronized. This will happen as a result of a frame being lost in transit if LAPB is not used. In this case, a new configure-request must be sent, and the CCP will drop out of the open state. Upon receipt of the configure-ack, the predictor tables are cleared to zero, and compression can be resumed without data loss. C. CCP Recommended Options The following Configurations Options are recommended: IP-Compression-Protocol -- with at least 4 slots, usually 16 slots. IP-Address -- only on dial-up lines. Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., "The Point-to-Point Protocol", RFC in progress. [2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January 1990. [4] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November Dave Rand expires in six months [Page 16] DRAFT PPP Compression October 1993 1983. [5] Reynolds, J., Postel,J., "Assigned Numbers", RFC 1340, USC/Information Sciences Institute, March 1990. [6] Perkins, D., Hobby, R., "Point-to-Point Protocol (PPP) initial configuration options", RFC 1172, August 1990. [7] Carr, D., "PPP Gandalf FZA Compression Protocol", Work in progress. [8] Lutz, R., "PPP Stacker LZS Compression Protocol", Work in progress. [9] Simpson, W.A., "PPP Puddle Jumper Compression Protocol", Work in progress. [10] Dimitri, T.J., "PPP Microsoft LZ Compression Protocol", Work in progress. Acknowledgments Some of the text in this document is taken from RFCs 1171 & 1172, by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis. Information leading to the expanded IP-Compression option provided by Van Jacobson at SIGCOMM '90. The predictor algorithm was originally implemented by Timo Raita, at the ACM SIG Conference, New Orleans, 1987. Bill Simpson helped with the document formatting. Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 (805) 685 4455 Dave Rand expires in six months [Page 17] DRAFT PPP Compression October 1993 EMail: fbaker@acc.com Author's Address Questions about this memo can also be directed to: Dave Rand Novell, Inc. 2180 Fortune Drive San Jose, CA 95131 +1 408 321-1259 EMail: dave_rand@novell.com Dave Rand expires in six months [Page 18] DRAFT PPP Compression October 1993 Table of Contents 1. Introduction .......................................... 1 2. A PPP Control Protocol (NCP) for Compression .......... 2 2.1 Sending Compressed Datagrams .................... 2 3. CCP Configuration Options ............................. 4 3.1 Compression Type Negotiation Option (common) .... 5 3.2 Compression Type Negotiation Option (OUI/Proprietary) ................................................. 7 APPENDICES ................................................... 9 A. Common compression number identification .............. 9 B. Common compression algorithm definitions .............. 10 B.1 Predictor algorithm .......................... 10 B.2 Encapsulation for Predictor type 1 ........... 14 B.3 Encapsulation for Predictor type 2 ........... 15 C. CCP Recommended Options ............................ 16 SECURITY CONSIDERATIONS ................................... 16 REFERENCES ................................................... 16 ACKNOWLEDGEMENTS ............................................. 17 CHAIR'S ADDRESS .............................................. 17 AUTHOR'S ADDRESS ............................................. 18