diff options
Diffstat (limited to 'doc/rfc/rfc1553.txt')
| -rw-r--r-- | doc/rfc/rfc1553.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc1553.txt b/doc/rfc/rfc1553.txt new file mode 100644 index 0000000..c6aa92e --- /dev/null +++ b/doc/rfc/rfc1553.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group S. Mathur +Request for Comments: 1553 M. Lewis +Category: Standards Track Telebit Corporation + December 1993 + + + Compressing IPX Headers Over WAN Media (CIPX) + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state and + status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes a method for compressing the headers of IPX + datagrams (CIPX). With this method, it is possible to + significantly improve performance over lower speed wide area + network (WAN) media. For normal IPX packet traffic, CIPX can + provide a compression ratio of approximately 2:1 including both IPX + header and data. This method can be used on various type of WAN + media, including those supporting PPP and X.25. + + This memo ia a product of the Point-to-Point Protocol Extensions + (PPPEXT) Working Group of the IETF. Comments should be sent to + the authors and the ietf-ppp@ucdavis.edu mailing list. + +Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST + + This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT + + This phrase means that the definition is an absolute + prohibition of the specification. + + + + + + +Mathur & Lewis [Page 1] + +RFC 1553 CIPX December 1993 + + + SHOULD + + This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications should be + understood and carefully weighed before choosing a + different course. + + MAY + + This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + +Introduction + + Internetwork Packet Exchange (IPX) is a protocol defined by the + Novell Corporation [1]. It is derived from the Internet Datagram + Protocol (IDP) protocol of the Xerox Network Systems (XNS) family + of protocols. IPX is a datagram, connectionless protocol that does + not require an acknowledgment for each packet sent. The IPX + protocol corresponds to the network layer of the ISO model. + + Usually, there is a transport layer protocol above IPX. The most + common transport protocol is the Netware Core Protocol (NCP), which + is used for file server access. The Sequenced Packet Exchange + (SPX) is the reliable connection-based transport protocol commonly + used by applications. + + The IPX packet consists of a 30 octet IPX header, usually followed + by the transport layer protocol header. The NCP header is 6 octets + in length. The SPX header is 12 octets in length. + + Two strategies are described below for compressing IPX headers. + This specification requires that implementations of CIPX support + both IPX header compression strategies. These header compression + algorithms are based on those Van Jacobson described [2] for TCP/IP + packets. + The first strategy is to compress only the IPX header. This + compression algorithm can be used to compress any IPX packet, + without affecting the transport protocol. This algorithm + compresses a 30 octet IPX header into a one to seven octet header. + + 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. This algorithm compresses a 36 octet NCP/IPX + + + +Mathur & Lewis [Page 2] + +RFC 1553 CIPX December 1993 + + + header into a one to eight octet header. + + Lastly, it is possible and many times desirable, to use this type + of header compression in conjunction with some type of data + compression. + + Data compression technology takes many forms. Link bit stream + compression is a common approach over very low speed asynchronous + links, normally performed by modems transparently. Transparent bit + stream compression is also offered in some DSUs, routers and + bridges. Data compression can be provided using protocols such as + CCITT V.42bis[3], MNP 5, Lempel-Ziv, or LAPB[4]. + + When using both header and data compression, the sequence of + compression is important. When sending packets, data compression + MUST be done after header compression. Conversely when receiving + packets, data decompression MUST be done before header + decompression. + +IPX Compression Algorithm + + The normal 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) | + +-----------------------+ + + IPX PACKET HEADER + + The IPX header diagram above is shown without the field 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 + + + +Mathur & Lewis [Page 3] + +RFC 1553 CIPX December 1993 + + + header, and has required that this field be set to 0xFFFF. Since the + Checksum field remains constant, it is clear that the value can be + compressed. + + Where Checksums are implemented (not 0xFFFF), the Checksum MUST be + included in the compressed packet. Recalculating the checksum would + destroy the end-to-end reliability of the connection. Note that + Checksums are now implemented in the Fault Tolerant Servers. + + For most links, the Packet Length can be determined from the MAC + layer. There are cases in which the length cannot be determined from + the MAC layer. For example, some hardware devices pad packets to a + required minimum length. For links where it is not possible to + determine the IPX packet length from the MAC layer, packet length + needs to be included in the compressed packet. + + The Transport Control (Hops) field usually does not change between + two end-points. For the purposes of compression, we will assume that + it never changes, and will not examine this field when determining a + connection. + + The Packet Type 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. An IPX connection is the logical association between two + endpoints known by a given source and destination address pair. For + any specific IPX connection, the Destination and Source Address + fields are constant. + + Hence, the fields that may need to be included in the compressed IPX + header are the Checksum and the Packet Length. + + While using this IPX header compression algorithm, packets can be + lost. The loss of an Initial packet presents a problem. In this + case, if the sender later tries to send a compressed packet, the + receiving end cannot decompress the packet correctly. + + Sufficient information is not available in the IPX header to + determine when a re-transmission has occured. For this reason, it is + necessary that the sender of an Initial packet be guaranteed that the + packet has been received. Therefore, we provide a mechanism for + Confirmation of an Initial packet. + +NCP/IPX Header Compression + + Since most IPX packets are Netware Core Protocol packets (packet type + 17), compressing the NCP header will give us added performance. A + + + +Mathur & Lewis [Page 4] + +RFC 1553 CIPX December 1993 + + + minimal CIPX implementation MUST also implement NCP/IPX compression. + + +------------+ + | 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. If the NCP type is + 0x2222, this packet is a request from the client to the server. + Conversely if the NCP type is 0x3333, this is a response from the + server to the client. All other types of NCP packets are not + compressed at the NCP level, but are compressed at the IPX level. + The Create Connection (0x111), Destroy Connection (0x5555) and Server + Busy (0x9999) packets are not exchanged frequently enough to justify + special NCP compression. The Burst Mode (0x7777) packet is discussed + below. + + The connection number is a constant for a given connection. + + The sequence number is increased by one for each new request. Hence + the sequence number can be determined implicitly. The decompressor + + + +Mathur & Lewis [Page 5] + +RFC 1553 CIPX December 1993 + + + increments the sequence number for each compressed packet it receives + for a connection. + + The task number can change unpredictably, although it might remain + constant for several packets. If the NCP task number is different + from the last one for this connection, the NCP task number must be + included. + + If the NCP packet is lost, it will be retransmitted through the + normal transport layer mechanisms. The Initial NCP packet does not + require confirmation, as a re-transmitted packet can be easily + identified. This is accomplished by comparing the sequence number of + the packet to the sequence number of the previous packet. If the + sequence number is not exactly one greater than the previous packet, + a new Initial packet must be sent, although the same connection slot + may be used. + + In the event of compressed packet loss, the sequence number will be + too small. When the IPX Checksum is present, the loss can be + determined at the destination system by an incorrect checksum. When + there is no checksum present, the loss is more likely to be detected + upon receiving a later retransmission. + +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. + +SPX Packets + + SPX packets are typically used by applications which require + reliable service such as print servers. It is possible to apply a + similar NCP/IPX technique to SPX/IPX 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. + +Compression Header + + IPX compression should be negotiated by some means (eg. IPXCP or + IPXWAN). Each end must negotiate the desired options, such as the + maximum number of concurrent connections which will be maintained + in each direction. Once IPX compression is negotiated, all IPX + packets sent over that link have a CIPX header added to the + + + +Mathur & Lewis [Page 6] + +RFC 1553 CIPX December 1993 + + + beginning of the packet. The CIPX header is variable in length. + + The one octet CIPX header is added even when a regular IPX packet + is sent over the link. By including the CIPX header on every + packet, we support the ability to run CIPX over various WAN links + as if it were a normal IPX packet. It does not rely on any new + link specific packet demultiplexing. + + Implementations of this compression protocol must maintain send + and receive tables indicating the state of each connection. The + original 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 information to reconstruct the original + packet header. + + The CIPX packet header specifies the type of the packet and any + options for that packet. The minimum CIPX header is one octet in + length. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | | | | | | | | | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + | | | | |___|___|___|___ Packet Type + | | | | 0 Compressed + | | | | 1 Regular + | | | | 3 Confirmed Initial + | | | | 5 Confirm + | | | | 7 Unconfirmed Initial + | | | | 9 Reject + | | | | 11-15 Reserved + | | | | + |__ |__ |__ |___________________ Packet Type Dependent Flags + + FLAGS OCTET + + As can be seen above, the low order bits specify the packet type. + All Compressed packets have a lowest bit of zero. The other + packet types are odd numbers. + + Note that the Flags octet MUST NOT contain the value 0xFF. This + is necessary to distinguish the CIPX flags octet from a normal IPX + header with a 0xFFFF checksum field. It is important to be able + + + +Mathur & Lewis [Page 7] + +RFC 1553 CIPX December 1993 + + + to recognize a normal IPX header regardless of the state of + compression. It is possible with some link layer protocols such + as X.25 Permanent Virtual Circuits that one end of the link may + fail and start sending regular IPX packets without the CIPX + header. CIPX implementations MUST recognize this situation and + renegotiate the use of CIPX. + + Each packet type has associated flag bits, which are called Packet + Type Dependent Flags. Different packet types have different + Packet Type Dependent Flags. All bits that are reserved or are + not specified must be set to zero. + + Since none of the packet types other than Compressed currently + uses any of the flag bits, the packet type field could easily be + expanded. Any future expansion must ensure that at least one of + the bits in the Flags octet remains zero so the value cannot be + 0xFF. + +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 header to use to formulate the original packet header before + passing the packet up to IPX. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mathur & Lewis [Page 8] + +RFC 1553 CIPX December 1993 + + + ________________________________ Slot Number + | 0 Assume same as last packet + | 1 Included in packet + | + | ____________________________ Checksum + | | 0 Assume 0xFFFF + | | 1 Included in packet + | | + | | ________________________ Length + | | | 0 Determine from MAC length + | | | 1 Included in packet + | | | + | | | ____________________ Task Number (NCP only) + | | | | 0 Assume same as last packet + | | | | 1 Included in packet + | | | | + | | | | ________________ Reserved (Must be zero) + | | | | | | | + | | | | | | | ____ Packet Type + | | | | | | | | 0 Compressed Packet + v v v v v v v v + +---+---+---+---+---+---+---+---+ + | | | | | 0 | 0 | 0 | 0 | + +---+---+---+---+---+---+---+---+ + 7 6 5 4 3 2 1 0 + + 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. + +Slot Number + + The slot number flag indicates the slot number field 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 Initial + packet header. Slots are numbered starting at zero and continue to + the maximum number of slots minus one. + + By default, slot compression is disabled. If negotiated, slot + compression can be enabled for those slots which were created by the + Unconfirmed Initial packet. When set to one (1), the slot number + flag indicates the inclusion of the the slot number in the compressed + packet. When set to zero (0), the slot number flag indicates the + omission of the the slot number and specifies the use of the same + slot number as for the last packet. + + + + + +Mathur & Lewis [Page 9] + +RFC 1553 CIPX December 1993 + + + Implementation Note: + + Slot compression MUST only be enabled in a receiver which can + account for all erroneous and discarded packets. When a packet + has been discarded, the slot number is indeterminate for future + packets. The decompressor MUST discard all further packets + until a slot number is received. + +Checksum + + When set to one (1), the checksum flag indicates the compressed + packet will include the 2 octet checksum. When set to zero (0), + this flag indicates the omission of the checksum and the decompressor + is to assume the checksum is 0xFFFF. Note that meaningful checksums + must be included in the packet with the checksum flag set to one (1). + +Length + + When set to one (1), the length flag indicates the inclusion of the + IPX data length field in the compressed packet. When set to zero + (0), the length flag indicates the omission of the IPX data length + field in the compressed packet. + + This is the Length field from the original IPX packet header. It + specifies the length of IPX header and data in the packet prior to + compression. It does not include the CIPX compression field such as + flags, slot number, checksum, length field, or the NCP task number. + Note that it is preferable to determine the length field from the MAC + layer whenever possible, by subtracting the length of the compression + header fields and adding the length of the saved packet header. + + 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, two or three octet field. If the length is in + the range 0 to 127, then it is specified as a one octet field. If + the length is in the range 128 to 16383, it is specified as a two + octet field in high to low order, with the first octet in the range + 128 to 191. Otherwise, if the length is greater than 16383, the + first octet contains 192, and the second and third octets contain the + full length. (This scheme is extensible to 8 octets, but currently + is not required in the IPX protocol suite.) + + + + + + + + + + +Mathur & Lewis [Page 10] + +RFC 1553 CIPX December 1993 + + + +-+-+-+-+-+-+-+-+ + |0| length | length < 128 + +-+-+-+-+-+-+-+-+ + + ONE OCTET LENGTH FIELD + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0| length | length < 16384 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + TWO OCTET LENGTH FIELD + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 1 0 0 0 0 0 0| length | length < 65535 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + THREE OCTET LENGTH FIELD + + +Task Number + + When set to one (1), the NCP task number flag indicates the NCP task + number is included in the compressed packet (see NCP/IPX compression + above). When set to zero (0), the NCP task number flag indicates the + omission of the NCP task number in the compressed packet. When the + NCP task number is not included in the compressed packet, we use the + same NCP task number as that of last packet. + + Based upon the bits set in the flags octet, optional portions are + included in 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 header. The maximum + compressed IPX header can include up to 7 octets, the Flags, Slot, + Checksum (2 octets), and Length (3 octets) fields, or 8 octets if the + NCP Task Number is included. The minimum and maximum compressed IPX + packets are shown below. Header fields are one octet in length + except where noted. + + + + + + + + + + + + + + +Mathur & Lewis [Page 11] + +RFC 1553 CIPX December 1993 + + + +--------+--------- + | Flags | DATA ... + | 0x00 | + +--------+--------- + + MINIMUM COMPRESSED IPX PACKET + + +--------+--------+---------+---------+--------- + | Flags | Slot |Checksum | Length | DATA ... + | 0xE0 | Number |2 octets |3 octets | + +--------+--------+---------+---------+--------- + + MAXIMUM COMPRESSED IPX PACKET + + +--------+--------+---------+---------+--------+--------- + | Flags | Slot |Checksum | Length |NCP Task| DATA ... + | 0xF0 | Number |2 octets |3 octets | Number | + +--------+--------+---------+---------+--------+--------- + + MAXIMUM COMPRESSED NCP/IPX PACKET + +Regular Packet + + The Regular packet type designates an IPX packet for which no + compression is desired. This type of packet is sent when a packet + cannot be compressed, or a decision is made not to compress it. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + | | | | |___|___|___|___ Packet Type + | | | | 1 Regular + | | | | + |__ |__ |__ |___________________ Reserved (must be zero) + + The Regular packet is rarely sent. Usually, the Regular packet is + sent when there is not enough memory for the overhead of a new + compression slot. Also, this type is included for future unforeseen + changes to the IPX protocol which defeat the effectiveness of + compression. + + Implementation Note: + + The Regular Packet can be used for packets that are sporadic, + which are not worth setting-up a compression slot. This may be + + + +Mathur & Lewis [Page 12] + +RFC 1553 CIPX December 1993 + + + hard to determine for specific protocols. Various methods such + as hold-down and least-recently-used timers are currently being + used. + + On receipt, the 1 octet header is simply removed and the packet + passed up to IPX. + + The entire IPX packet follows the single Flags octet. Note for a + Regular Packet (not compressed or uncompressed), the slot number + field is not included. + +Confirmed Initial Packet + + The Confirmed Initial packet type is used by the compressor to inform + the decompressor of the original packet header which will be used for + subsequent compression, and to request Confirmation. The high order + 4 bits are reserved for expansion to support additional protocols. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + | | | | |___|___|___|___ Packet Type + | | | | 3 Confirmed Initial + | | | | + |__ |__ |__ |___________________ 0 IPX Protocol + 1-15 Reserved + + This type of packet is sent to inform the receiver to associate the + IPX packet header with a slot number. This packet is sent each time + a different header format is sent for a given slot, or when the + sender has not received a Confirmation Packet from the receiver. + + The Flags octet lower 4 bits indicate the Confirmed Initial CIPX + packet type. The high order 4 bits are reserved for expansion to + support additional protocols. The Flags octet is always followed by + the Slot Number and an ID field. The ID field is one octet in + length. + + For each slot, the ID will increment with every new header sent. + Different slots may have the same ID. The combination of slot and ID + uniquely identify a header. In practice, the ID 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 slot and ID combinations within this period. Otherwise, + + + +Mathur & Lewis [Page 13] + +RFC 1553 CIPX December 1993 + + + there is ambiguity as to which header is being identified. + + Implementation Note: + + There is no requirement to hold or resend the Confirmed Initial + packet until confirmation. When a new packet with the same IPX + header is to be sent, another Confirmed Initial packet should + be sent using the same slot, the same ID, and the new packet + data. + + When a new packet with a different IPX header is to be sent, it + may be sent using a slot which has not received confirmation. + A Confirmed Initial packet is sent with the same slot, an + incremented ID, and the new packet data. Assuming a least- + recently-used policy for selecting a slot for a new IPX header, + this provides the ability to reuse slots when a Confirmed + Initial packet has been sent but not confirmed. + + +---------+---------+---------+-/ /-+---------- + | Flags | Slot | ID | IPX | DATA ... + | 0x03 | Number | | Header | + +---------+---------+---------+-/ /-+---------- + +CONFIRMED INITIAL PACKET + + Note that a Confirmed Initial header is followed by a complete IPX + packet. + +Confirm Packet + + The Confirm packet type is used by the decompressor to tell the + compressor that it has received the Confirmed Initial packet. + + When the compressor receives this, it can start sending Compressed + frames. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + | | | | |___|___|___|___ Packet Type + | | | | 5 Confirm + | | | | + |__ |__ |__ |___________________ Reserved (must be zero) + + A Confirm Packet is exactly 3 octets in length. It consists of the + + + +Mathur & Lewis [Page 14] + +RFC 1553 CIPX December 1993 + + + Flags, Slot Number and ID fields. The Slot Number field contains the + number of the slot which is being acknowledged. The ID field + contains the ID of the Confirmed Initial Packet which is being + acknowledged. + + +---------+---------+----------+ + | Flags | Slot | ID | + | 0x05 | Number | | + +---------+---------+----------+ + +CONFIRM PACKET + +Unconfirmed Initial Packet + + The Unconfirmed Initial packet type is used by the compressor to + inform the decompressor of the original packet header which will be + used for subsequent compression while not requesting confirmation. + + After sending an Unconfirmed Initial packet, the compressor may + immediately send Compressed packets without confirmation. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + | | | | |___|___|___|___ Packet Type + | | | | 7 Unconfirmed Initial + | | | | + |__ |__ |__ |___________________ 0 NCP Protocol + 1-15 Reserved + + This type of packet is sent to inform the receiver to associate the + IPX packet header with a slot number. This packet is sent each time + a different header format is sent for a given slot. + + The Flags octet lower 4 bits indicate the Unconfirmed Initial CIPX + packet type. The high order 4 bits are reserved for expansion to + support additional protocols. The Flags octet is always followed by + the Slot Number. + + +---------+---------+-/ /-+-/ /-+--------- + | Flags | Slot | IPX | NCP | NCP + | 0x07 | Number | Header | Header | DATA ... + +---------+---------+-/ /-+-/ /-+--------- + + + + + +Mathur & Lewis [Page 15] + +RFC 1553 CIPX December 1993 + + +UNCONFIRMED INITIAL PACKET + + + Note that an Unconfirmed Initial header is followed by a complete IPX + packet. + +Reject Packet + + The Reject packet type is used by the decompressor to tell the + compressor that it has received a CIPX packet with a header which it + does not support. This is provided to regulate future extensions to + CIPX. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | | + | | | | |___|___|___|___ Packet Type + | | | | 9 Reject + | | | | + |__ |__ |__ |___________________ Reserved (must be zero) + + A Reject Packet is exactly 3 octets in length. It consists of the + Flags, Slot Number and Rejected Flags fields. + + The Slot Number field contains the number of the slot of the packet + which is being rejected. Since the actual packet type may be unknown + or misunderstood, this field actually contains the second octet of + the rejected packet. In the normal case of a known CIPX packet type, + this will be the slot number of an initial packet. + + The Rejected Flags field contains the first octet of the packet being + rejected. The packet type field is left untouched. Any flags which + are correctly recognized should be cleared. The remaining flags + indicate specific features that are being rejected. This information + should be sufficient for implementations to adjust the use of certain + packet types or dependent flags. + + Implementation Note: + + The Flags value of 0xFF is not a valid CIPX packet type. + Hence, such a packet type should be recognized as a standard + IPX header and forwarded without CIPX processing to the + appropriate routines. Under no circumstances should a Flags + value of 0xFF be rejected in a Reject Packet. + + + + +Mathur & Lewis [Page 16] + +RFC 1553 CIPX December 1993 + + + +---------+---------+----------+ + | Flags | Slot | Rejected | + | 0x09 | Number | Flags | + +---------+---------+----------+ + + REJECT PACKET + +Compression Negotiation over PPP Links + + For PPP links [5], the use of header compression can be negotiated by + IPXCP [6]. By default, no compression is enabled. + + The IPX-Compression-Protocol Configuration Option is used to indicate + the ability to receive compressed packets. Each end of the link must + separately request this option if bi-directional compression is + desired. + + The PPP Protocol field is set to the same value as the usual IPX + packets, and all IPX packets sent over the link MUST conform to the + compressed format. + + 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 + + + +Mathur & Lewis [Page 17] + +RFC 1553 CIPX December 1993 + + + slot identifier. This is one less than the actual number of + slots; the slot identifier has values from zero to Max-Slot- + Id. + +Options + + The Options field is one octet, and is comprised of the "logical or" + of the following values: + + 0 No options. + + 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. + + 2 Redefine Compressed Packet type bits 1-3. + + It was noted earlier that packet types have been chosen such + that only the Compressed Packet type is an even number value + with the lowest order bit of zero. All other packet types are + odd values with a lowest order bit of one. The reason for this + assignment was to make it possible to determine the Compressed + Packet type by examining only one bit. This make it possible + to use all the other 7 bits to indicate status in the + Compressed Packet. The 7 bits are composed of the upper 4 bits + which are permanently defined to indicate packet dependent + flags, plus bits 1-3 which are otherwise part of the Packet + Type. The upper 4 bits are defined above. The redefinition of + bits 1-3 of the Compressed Packet type is left for future + expansion. + + 7 6 5 4 3 2 1 0 + +---+---+---+---+---+---+---+---+ + | | | | | | | | 0 | + +---+---+---+---+---+---+---+---+ + ^ ^ ^ ^ ^ ^ ^ ^ + | | | | | | | |___ Packet Type + | | | | | | | 0 Compressed Packet + | | | | | | | + | | | | |___|___|_______ Redefined bits + | | | | + |___|___|___|___________________ Compressed Packet flags + + By default, this feature in not enabled and this flag is + set to zero. When this flag is set to one, it indicates + + + +Mathur & Lewis [Page 18] + +RFC 1553 CIPX December 1993 + + + the desire to use this feature. + +Compression Negotiation over IPXWAN Links + + "IPXWAN" is the protocol Novell uses to exchange necessary router + to router information prior to exchanging standard IPX routing + information and traffic over WAN datalinks [7]. To negotiate the + Telebit compression option, we use Novell's allocated option number + for CIPX (00) in 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 + 0x02 Redefine Compressed Packet type bits 1-3. + + 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 + + + + + +Mathur & Lewis [Page 19] + +RFC 1553 CIPX December 1993 + + + 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 + 0x02 Redefine Compressed Packet type bits 1-3. + + 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 + negotiations 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 + remaining options. Options, by definition, are not required. + Implementations 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 symmetrical 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 + different 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. + + + + + + +Mathur & Lewis [Page 20] + +RFC 1553 CIPX December 1993 + + + 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 NCP/IPX header is 8 octets (including the NCP task + number), but since no implementation yet sends packets with a length + greater than 16K, 7 octets is the commonly encountered maximum. + Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the + inclusion of the flag and slot number octets. + + The maximum length of the data in an IPX packet is 546 octets (576 + octets - 30 octet IPX header), although newer implementations may + send packets of up to 4096 octets. The minimum length of the data in + an IPX packet is 1 octet. Within the normal distribution of small + NCP packets, perhaps a reasonable 'avg_data_len' is 26 octets. + + 546 + 30 + Minimal Compression = -------- = 1.04 + 546 + 6 + + 1 + 30 + Maximal Compression = ------ = 15.50 + 1 + 1 + + 26 + 30 + Likely Compression = ------- = 2.00 + 26 + 2 + + +Security Considerations + + IPX provides some security features, which are fully applicable to + CIPX. CIPX does not significantly alter the basic security of IPX. + + + + + + + + + + + + + +Mathur & Lewis [Page 21] + +RFC 1553 CIPX December 1993 + + +References + + [1] Novell Inc., "IPX Router Specification", September 1992, Part + Number: 107-000029-001 + + [2] Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial + Links", RFC 1144, February 1990 + + [3] CCITT Recommendation V.42bis Error Correcting Procedures for DCEs + using Error Correction Procedures + + [4] ISO 7776, Information Processing Systems - Data Communication - + High Level Data Link Control Procedures - Description of the X.25 + LAPB-Compatible DTE Data Link Procedures + + [5] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1548, + December 1993 + + [6] Simpson, W. A., "The PPP Internet Packet Exchange Control + Protocol (IPXCP)", RFC 1552, December 1993 + + [7] Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]", + RFC 1551, December 1993 + +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. David Piscitello from Bellcore and Marty + Del Vecchio at Shiva Corp. made several good suggestions. Bill + Simpson was very helpful in driving PPP, and specifically IPXCP, on + the standards course. + +Chair's Address + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California 93117 + + EMail: fbaker@acc.com + + + + + + + + + +Mathur & Lewis [Page 22] + +RFC 1553 CIPX December 1993 + + +Authors' Addresses + + 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 23] + |