Internet Working Group Saroop Mathur Internet Draft Mark S. Lewis Telebit Corp. December 1992 Expire: July 1993 Compressing IPX Headers Over WAN Media (CIPX) Status of this Memo This draft is a proposed elective protocol for the Internet community and requests discussion and suggestions for improvement. This docu- ment is being submitted to the Internet Engineering Task Force (IETF) through the Point-to-Point Protocol Working Group. Comments should be sent to the authors and 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 IETF, its Areas, and it's Working Groups. Internet Drafts are valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. Abstract This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, is is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX will provide a compression ratio of approximately 2:1. This method can be used on various type of WAN media, including those supporting PPP, IPXWAN and X.25. Mathur, Lewis [Page 1] Internet Draft CIPX December 1992 Table of Contents Introduction ................................................... 3 IPX Compression Algorithm ...................................... 4 IPX Compression Flag Octet ..................................... 6 IPX Compression Error Handling ................................. 9 IPX/NCP Header Compression ..................................... 11 IPX/NCP Compression Error Handling ............................. 13 Compression Negotiation over PPP Links ......................... 14 Compression Negotiation over IPXWAN Links ...................... 16 IPX Compression Performance .................................... 17 SPX Packets .................................................... 18 NCP Burst Mode Packets ......................................... 18 Security Considerations ........................................ 19 References ..................................................... 19 Acknowledgements ............................................... 19 Author's Address ............................................... 19 Mathur, Lewis [Page 2] Internet Draft CIPX December 1992 Introduction This document describes a header compression algorithm for IPX pack- ets sent over low-speed links. IPX is a protocol defined by the Novell Corporation. It is similar to the IDP protocol of the Xerox's XNS family of protocols. The IPX protocol corresponds to the network layer of the ISO model. Usually, there is a transport layer protocol above IPX. In the case of IPX, by far the most common upper layer protocol is the Netware Core Protocol (NCP). SPX is the reliable connection-based transport protocol commonly used by applications. The throughput of IPX packets sent over low-speed serial lines can be significantly improved by the use of header compression. This is par- ticularly true in the case of small packets. The IPX packet consists of a 30 octet IPX header usually followed by an upper layer protocol header. In the case of Netware file server packets, the upper layer protocol is NCP. NCP includes a 6 octet header following the IPX header. The SPX header is 12 octets which follow the IPX header Two strategies are described below for compressing IPX headers. The first strategy is to compress only the IPX header. This compression algorithm can be used to compress any IPX packet. The upper layer protocol is irrelevant. Typically, this algorithm compresses a 30 octet IPX header into a two octet header composed of flag and slot number octets. The second strategy is to compress the combined IPX and NCP headers. This algorithm compresses only NCP packets with NCP type of 0x2222 and 0x3333. Typically, this algorithm compresses a 36 octet IPX/NCP header into a 2 octet compressed header containing flags and slot number. This specification requires that implementations of CIPX support both IPX header compression strategies. With both techniques, NCP pack- ets with NCP type of 0x2222 and 0x3333 will have their 36 octet IPX/NCP headers compressed to 2 octets while all other packets will have their 30 octet IPX header compressed to one or two octets. Lastly note that is possible, and many times desirable, to use this type of header compression in conjuction with some type of data compression. After intelligently compressing the packet header, data compression can be effective in reducing packet size further. It is important that data compression should be done after header compres- sion. Conversely, data uncompression should be done before header uncompression. Mathur, Lewis [Page 3] Internet Draft CIPX December 1992 IPX Compression Algorithm The following is the description of a header compression algorithm for IPX. This algorithm is based on the header compression algorithm for TCP/IP packets written by Van Jacobson [1]. This algorith can be used over various WAN media. Option negotiation and packet encapsu- lation are separate issues. IPX compression must be negotiated by some means (eg. IPXCP or IPXWAN). Each end must neotiate the desired options such as the max- imum number of slots. Once IPX compression is negotiated, all IPX packets sent over that link have a one or more octet header prepended to the packet. A one octet header is prepended if a regular IPX packet is sent over the link. By including the header, we support the ability to run CIPX over various WAN protocols. It does not rely on any new protocol specific packet types. Implementations of this compression protocol, must maintain send and receive tables indicating the state of each connection. The IPX header for each connection is stored in a 'slot'. Typically, each client-server connection will use a separate slot. Both sides keep a copy of the full IPX header corresponding to each slot. The sending side (compressor) uses this information to determine the fields that have changed. The receiving side (decompressor) uses this informa- tion to reconstruct the packet header. The normal uncompressed IPX header consists of the following fields: checksum, packet length, transport control (hop count), packet type, destination and source address fields. +-----------------------+ | Checksum | +-----------------------+ | Packet Length | +-----------+-----------+ | Hops |Packet Type| +-----------+-----------+ | Destination | | Address | | (12 Octets) | +-----------------------+ | Source | | Address | | (12 Octets) | +-----------------------+ NORMAL IPX HEADER The IPX header diagram above is shown without the unnecessary field Mathur, Lewis [Page 4] Internet Draft CIPX December 1992 alignment details. Consider each field of the IPX header separately, and how it typically changes. Historically, Novell has not used the checksum field in the IPX header and has required that this field be set of 0xFFFF. Since checksums remain constant, it is clear that checksum can be compressed. When checksum are implemented, it will be necessary to include the checksum in a compressed packet. It is not possible to compress meaningful checksums over unreliable links. Data can become cor- rupted and will go undetected. Without end to end checksums, it is impossible to detect such errors. For most links, the length of the packet can be determined from the MAC layer. There are cases in which the length cannot be determined fom the MAC layer. For example, some hardware devices want to pad packets to a required length. For links where it is not possible to determine the IPX packet length from the MAC packet length, packet length needs to be specified with the compressed packet. The Transport Control (Hops) field usually does not change between two end-points. The protocol field is constant for any connection. The destination and source address fields are each made up of 12 octets: Network (4 octets), Node (6 octets), and Socket (2 octets) fields. For any specific IPX connection, the destination and the source address fields are constant. Hence, the fields that may need to be included in the compressed header are the checksum and the packet length. Mathur, Lewis [Page 5] Internet Draft CIPX December 1992 IPX Compression Flag Octet The flags field specifies the type of the packet and any options for that packet. The flags is one octet in length. The following values are currently defined for the flags field: 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | | | | | | | | | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 0 Regular Packet | | | | | 1 Compressed Packet | | | | | 2 Uncompressed Packet | | | | | 3 ACK for Uncompressed | | | | | 4-7 Reserved | | | | | | | | | |_______________ Reserved (Must be zero) | | | | |__ |__ |__ |___________________ Packet Type Dependent Flags FLAGS OCTET As can be seen above, the low order 3 bits specify the packet type. There are four basic packet types. The regular packet type desig- nates an IPX packet for which no compression is desired. The compressed packet type of course designated the packet as compressed. The uncompressed packet type is used by the compressor to inform the decompressor of the packet header format which will be used for sub- sequent compression. (The compressor has determined the IPX packet is compressible and no connection state has been found that matches the packet's source and destination address, hop count and packet type.) The ACK for Uncompressed packet type is used by the decompres- sor to tell the compressor that it understands the packet header for- mat. Note that the flags octet may not contain the value 0xFF. This is necessary to distinguish the CIPX flags octet from a normal IPX header with a 0xFFFF checksum. It is important to be able to recog- nize a normal IPX header regardless of the state of compression. It is always possible that one end of the link may fail and start send- ing normal uncompressed IPX packets. Bit 3 must alway be set to zero to prevent the flag octet from containing 0xFF. All bits that are reserved or are not specified must be set to zero. For each different packet type, there are associated flag bits. At this time, flag bits are only defined for the compressed packet type. Mathur, Lewis [Page 6] Internet Draft CIPX December 1992 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | | | | | | 0 | 0 | 1 | +---+---+---+---+---+---+---+---+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | |___|___|___ Packet Type | | | | | 1 Compressed Packet | | | | | | | | | |_______________ Reserved (Must be zero) | | | | | | | |___________________ NCP Task Number | | | 0 Assume same as last packet | | | 1 Included in packet | | | | | |_______________________ Length | | 0 Determine from MAC length | | 1 Included in packet | | | |___________________________ Checksum | 0 Assume 0xFFFF | 1 Included in packet | |_______________________________ Slot ID 0 Assume same as last packet 1 Included in packet FLAGS OCTET - COMPRESSED PACKET Consider each flag in the flags octet, looking at the high order bits working toward the lower order bits. Each of the fields is optional, but if present, will be found in the same order in the compressed packet header. The slot number flag indicates the slot number is included in the compressed packet. The slot number field is one octet in length and specifies the number of the slot which corresponds to the uncompressed packet header. Slots are number starting at zero and continue to the maximum number of slots minus one. This feature depends if slot compression is negotiated. By default, slot compression is disabled. If negotiated, slot compression can be enabled. If slot compression is enabled, the decompressor assumes the same slot number as the last packet received. When this assump- tion is inappropriate, the compressor sets the slot number flag and includes the correct slot number. Typically, the slot number will be included when sending a compressed packet for a slot different than that of the last packet. Note for a regular IPX packet, (not compressed or uncompressed), the slot number field should not be included. Mathur, Lewis [Page 7] Internet Draft CIPX December 1992 If the checksum flag is set, the compressed packet will include the 2 octet checksum. If this flag is not set, then the decompressor assumes the checksum is 0xFFFF. Note that meaninful checksums must be included in the packet with the flag set. The length flag indicates the inclusion of the IPX data length field in the compressed packet. If the length field is included, it speci- fies the length of IPX data in the uncompressed packet. It does not include the flags, slot number, the checksum, the length field, or the NCP task number. Note it is preferable to determine the length field from the MAC layer whenever possible. Since every octet is significant over lower speed WAN links, an optimization is used in the specification of the length. It can be specified as a one or a two octet field. If the length is less than 128, then it is specified as a one octet field. Otherwise, it is specified as a two octet field in high to low order with the high order bit set to one. +-+-------+ |0| length| Length of Data < 128 +-+-------+ ONE OCTET LENGTH FIELD +-+-------+---------+ |1| length | 128 <= Length of Data < 32768 +-+-------+---------+ TWO OCTET LENGTH FIELD The NCP task number flag indicates the NCP task number is included in the compressed packet (see IPX/NCP compression below). Otherwise, we use the same NCP task number as that of last packet. Based upon the flags set in the flags octet, we will include optional portions of the compressed IPX header. The minimum compressed IPX header contains only the flags octet. All fields in the original IPX header have been compressed out of the compressed header. The max- imum compressed IPX header can include up to 6 octets. It can include the flags, slot id, checksum (2 octets), and length (2 octets) fields. The minimum and maximum compressed IPX packets are shown below. Header fields are one octet in length except where noted. Mathur, Lewis [Page 8] Internet Draft CIPX December 1992 +--------+--------- | Flags | DATA ... | 0x01 | +--------+--------- MINIMUM COMPRESSED IPX PACKET +--------+--------+---------+---------+--------- | Flags | Slot |Checksum | Length | DATA ... | 0xE1 | Number |2 octets |2 octets | +--------+--------+---------+---------+--------- MAXIMUM COMPRESSED IPX PACKET IPX Compression Error Handling While using this IPX header compression algorithm, packets can be lost. This algorithm handles the loss of each type of packet. If an normal IPX packet is lost, the upper layer protocols will handle the problem. Likewise if compressed packets are lost, the upper layer protocols will handle the problem. This algorithm need not do any- thing special in these cases. However, the loss of an uncompressed packet presents a problem. In this case, if the sender later tries to send a compressed packet, the receiving end cannot uncompress the packet correctly. For this rea- son, it is necessary that the sender of an uncompressed packet be guaranteed that the packet has been received. Note that an uncompressed IPX packet is identical to a regular IPX packet except for the additional flags octet, the slot number field, and an iden- tification octet. The ID octet is maintained by incrementing it for each new header sent for a designated slot. For each slot, the ID will increment with every new header sent. Different slots will have the same ID. The combination of slot and ID uniquely identify a header format. In practice, the identification octet can be any number which is unique for a 'reasonably long period' of time. A reasonably long period is a function of transmission speed, round trip delays, and network load. There must be very little chance of duplicate IDs within this period. Otherwise, there is ambiquity as to which header format is being identified. The receiver of an uncompressed packet acknowledges receipt of an uncompressed packet with an 'ACK for Uncompressed' packet. An IPX ACK for uncompressed packet is exactly 3 octets in length. It con- sist of the flags, the slot number and ID fields. The slot number field contains the number of the slot which is being acknowledged. Mathur, Lewis [Page 9] Internet Draft CIPX December 1992 The ID field contains the ID which is being acknowledged. +---------+---------+----------+---------- | Flags | Slot | ID | DATA ... | 0x02 | Number | | +---------+---------+----------+---------- UNCOMPRESSED PACKET +---------+---------+----------+ | Flags | Slot | ID | | 0x03 | Number | | +---------+---------+----------+ ACK FOR UNCOMPRESSED PACKET Here is a summary of the four packet types and how each is handled. The details of IPX/NCP header are discussed in a following section. Regular Packet This type of packet is sent when a packet can- not be compressed, or a decision is made not to compress. On receipt, the 1 byte compres- sion header is simply removed and the packet passed up to IPX. Compressed Packet This type of packet does not contain a packet header (either 30 byte IPX, or 36 byte NCP). A slot number indicates to the receiver which saved slot to use to formulate the packet header before passing the packet up to IPX. Uncompressed Packet This type of packet is sent to inform the receiver to associate the packet header with the slot number. This type of packet is sent each time a different header format is sent for a given slot, or when the sender has not received an acknowledgement from the receiver. ACK Uncompressed This type of packet acknowledges the receipt of an Uncompressed frame. When the sender receives this, he can start sending compressed frames. Mathur, Lewis [Page 10] Internet Draft CIPX December 1992 IPX/NCP Header Compression Since most IPX packets are Netware packets (packet type 17), compressing the upper layer protocol (NCP) header will give us added performance. +------------+ | NCP | | Type | +------------+ | Sequence | | Number | +------------+ | Connection | |(low octet) | +------------+ | Task | | Number | +------------+ | Connection | |(high octet)| +------------+ NCP HEADER The NCP header is 6 octets in length consisting of the following fields: NCP type, sequence number, connection number and task number. The NCP type field values that are currently defined are: 1111 Create Connection 2222 NCP request from workstation 3333 NCP reply from file server 5555 Destroy Connection 7777 Burst Mode Packet 9999 Server Busy Packet This NCP header compression algorithm only compresses packets that have a type field value of 0x2222 or 0x3333. All other types of pack- ets are not compressed at the NCP level. If NCP type equals 0x2222, then this packet is a request from the client to the server. If NCP type is 0x3333, then this is a response from the server to the client. In the NCP header, the connection number is a constant for a given connection. So the only fields that change in a given direction are Mathur, Lewis [Page 11] Internet Draft CIPX December 1992 the sequence number and the task number. The sequence number is usu- ally increased by one for each new request. Hence the sequence number can be determined implicitly. The task number can change unpredict- ably although it can remains constant for several packets. The minimum compressed IPX/NCP header is octet. The maximum compressed IPX/NCP header is 7 octets. The minimum and maximum compressed IPX/NCP headers look as follows. Header fields are one octet in length except where noted. +--------+--------- | Flags | DATA ... | 0x01 | +--------+--------- MINIMUM COMPRESSED IPX/NCP PACKET +--------+--------+--------+--------+--------+--------- | Flags | Slot |Checksum| Length |NCP Task| DATA ... | 0xF1 | Number |2 octet |2 octet | Number | +--------+--------+--------+--------+--------+--------- MAXIMUM COMPRESSED IPX/NCP PACKET An uncompressed NCP packet has the same format as that of an uncompressed IPX packet. The receiving end knows it is an uncompressed NCP packet because the IPX packet type is 17, and the NCP packet type is either 0x2222 or 0x3333. An uncompressed IPX/NCP packet has the following summarized format: +-------+--------+------------+-----------+--------- | Flags | Slot | IPX | NCP | NCP | 0x02 | Number | Header | Header | DATA ... +-------+--------+------------+-----------+--------- UNCOMPRESSED IPX/NCP PACKET An uncompressed NCP packet does not require an ACK as a re-transitted packet can be easily identified and should be sent uncompressed. The receiving end can regenerate the entire IPX and NCP header from the saved header and the compressed packet. The IPX header will be identical to the IPX header in the uncompressed packet, except the length needs to be inserted. Since the length can be known from the MAC packet size or the explicit length field, the IPX header can be generated. The NCP header will be the same as the IPX header in the Mathur, Lewis [Page 12] Internet Draft CIPX December 1992 uncompressed packet, except the sequence number and task numbers may be different. The sequence number is generated from the sequence number of the last packet. It is expected that there will be consecutive NCP packets with the same task number. In this case, the NCP task number can be assumed from the last packet. If the NCP task number is different than the last one for this slot, then the NCP task number must be included. In this case, the NCP task number flag is set and the NCP task number is included in the compressed packet. IPX/NCP Compression Error Handling If an NCP packet is lost, it will be retransmitted. If the compressor does not detect this re-transmitted packet and compress it as usual, the uncompressor will increment the sequence number. Needless to say, this can cause serious problems. To avoid this situation, the compressor should detect re-transmitted packets. This is accomplished easily by comparing the sequence number of the packet to the sequence number of the previous packet. In case these are same, it is a re- transmitted packet. A retransmitted packet should always be sent uncompressed. Mathur, Lewis [Page 13] Internet Draft CIPX December 1992 Compression Negotiation over PPP Links For PPP links [2], the use of header compression can be negotiated by the IPXCP [3]. By default, no compression is enabled. If both sides of the PPP link agree on the compression algorithm, then IPX header compression is enabled. During negotiation, the number of connection slots and whether or not to compress the slot id is determined. For the number of slots, it is chosen as the lower of the two requests. It must be the same for both sides of the connection. A summary of the IPX-Compression-Protocol Configuration Option format to negotiate Telebit IPX header compression (CIPX) 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 | IPX-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot-Id | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 6 IPX-Compression-Protocol 0002 (hex) for Telebit Compressed IPX headers (CIPX) Max-Slot-Id The Max-Slot-Id field is one octet and indicates the maximum slot identifier. This is one less than the actual number of slots; the slot identifier has values from zero to Max-Slot-Id. The number of requested slots can be 1 - 255. The negotiated number must be the lower of the two requested values. Options The Options field is one octet, and is comprised of the "logical or" of the following values: 0 No options. Mathur, Lewis [Page 14] Internet Draft CIPX December 1992 1 The slot identifer may be compressed. The slot identifier must not be compressed if there is no ability for the PPP link level to indicate an error in reception to the decompression module. Synchronization after errors depends on receiving a packet with the slot identifier. All IPX packets whether compressed or not have a protocol type of 0x002b on links supporting PPP [3]. Mathur, Lewis [Page 15] Internet Draft CIPX December 1992 Compression Negotiation over IPXWAN Links "IPXWAN" is the protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing informa- tion and traffic over WAN datalinks [4]. To negotiate the Telebit compression option, we add an option to the IPXWAN timer request/response packet. The Timer Request packet contains the following Telebit compression option: WOption Number 80 - Define compression type WAccept Option 01 - 0=No, 1=Yes, 3=N/A WOption Data Len 00 03 - Length of option WOption Data 00 - Telebit's compression (CIPX) WOption Data XX - Compression options WOption Data NN - Compression slots Where the WOption Data fields are: 00 Telebit's compression option described in this document (CIPX). XX Compression options as defined below: 0x01 Compress slot ID when possible NN The requested # of compression slots. Accept Option (for compression type) must be set to YES if the option is supported and NO if the option is not supported. A Timer Response must respond with only one header compression type set to YES. The Timer Response packet that accepts the option will look like this: WOption Number 80 - Define compression type WAccept Option 01 - 0=No, 1=Yes, 3=N/A WOption Data Len 00 03 - Length of option WOption Data 00 - Telebit's compression (CIPX) WOption Data XX - Compression options WOption Data NN - Compression slots Where the WOption Data fields are: 00 Telebit's compression option described in this document (CIPX). XX Compression options as defined below: 0x01 Compress slot ID when possible Mathur, Lewis [Page 16] Internet Draft CIPX December 1992 NN The negotiated # of slots (The lower of each side's requested number of slots) IPX packets (except of course IPXWAN packets) are not sent over the link until the IPXWAN negotiations are completed. Once IPXWAN nego- tiations are completed, regular IPX packets can be sent over the link. If both ends of the link agree on the compression options, then the IPX packets are sent using the specified options. If either end of the link does not accept a compression option, then this compression option will not be used. Compression will be done using any remain- ing options. Options, by definition, are not required. Implementa- tions MUST support CIPX without any options. It is the responsibility of the router sending the IPXWAN Timer Response to inform the other router of the options that will be used. The Timer Response MUST contain a subset of the options received in a Timer Request. To be clear, IPXWAN is used to set up a symetrical compression link. Compression is configured identically in both directions. Each end will use the same number of slots and same compression options. It is illegal for link ends to use different number of slots or dif- ferent options. IPX Compression Performance The performance of this algorithm will depend on the number of active connections and the number of slots negotiated. If the number of slots is greater than the number of connections, the hit rate should be very high giving a very high compression ratio. The performance also depends on the average size of the IPX packets. If the average size of packets is small, then compression will result in a more noticeable performance improvement. avg_data_len + uncomp_header_len Compression ratio = ---------------------------------- avg_data_len + avg_comp_header_len Where 'avg_data_len' is the average length of data in the IPX packet, and 'uncomp_head_len' is the uncompressed header length which is fixed at 30 octets. Where 'avg_comp_header_len' is the average length of the compressed IPX header. The length of the minimum compressed IPX header is 1 octet. The length of the maximum compressed IPX header is 6 octets (including the NCP task number). Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the inclu- sion of the flag and slot number octets. Mathur, Lewis [Page 17] Internet Draft CIPX December 1992 The maximum length of the data in a IPX packet is 546 octets (576 octets - 30 octet IPX header). The minimum length of the data in an IPX packet is 1 octet. With the normal distriubution of small NCP packets, perhaps a reasonable 'avg_data_len' is 28 octets (6 octet NCP header and 22 octet NCP data). 546 + 30 Minimum Compression = -------- = 1.04 546 + 6 1 + 30 Maximum Compression = ------ = 15.50 1 + 1 28 + 30 Reasonable Compression = ------- = 1.93 28 + 2 SPX Packets SPX packets are typically used by applications which require reliable service such as print servers. It is possible to apply a similar IPX/NCP technique to IPX/SPX packets. At this time, we have not described such a mechanism. The IPX header in this packet is still compressible with the IPX header compression algorithm described. NCP Burst Mode Packets The burst mode protocol uses the NCP type value of 0x7777. This type of packet does not have the normal NCP header described above. Instead, it has a 36 octet burst header. The above NCP header compression algorithm should not be used to compress this packet. The IPX header in this packet is still compressible with the IPX header compression algorithm described. Mathur, Lewis [Page 18] Internet Draft CIPX December 1992 Security Considerations Security issues are not discussed in this memo. References 1 Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990 2 Simpson, W. A., "The Point-to-Point Protocol (PPP) for the Transmis- sion of Multi-protocol Datagrams over Point-to-Point Links", RFC 1331, May 1992. 3 Simpson, W. A., "The PPP Internet Packet Echange Control Protocol (IPXCP)", an internet draft which is work in process, October 1992 4 Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]", RFC 1362, August 1992 Acknowledgements This compression algorithm incorporates many ideas from the Van Jacobson TCP/IP header compression algorithm. Michael Allen from Novell provided a lot of valuable feedback in the design of this algorithm. Marty Del Vecchio at Shiva Corp. made a couple of good observations. Bill Simpson was, as always, very help- ful. Authors' Address Saroop Mathur Telebit Corp. 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 email: mathur@telebit.com Mark S. Lewis Telebit Corp. 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 email: Mark.S.Lewis@telebit.com Mathur, Lewis [Page 19]