As per Relevance of the word indicate, we have this rfc below:
Network Working Group S.
Request for Comments: 1553 M.
Category: Standards Track Telebit
December 1993
Compressing IPX Headers Over WAN Media (CIPX
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization state
status of this protocol. Distribution of this memo is unlimited
This document describes a method for compressing the headers of
datagrams (CIPX). With this method, it is possible
significantly improve performance over lower speed wide
network (WAN) media. For normal IPX packet traffic, CIPX
provide a compression ratio of approximately 2:1 including both
header and data. This method can be used on various type of
media, including those supporting PPP and X.25.
This memo ia a product of the Point-to-Point Protocol
(PPPEXT) Working Group of the IETF. Comments should be sent
the authors and the ietf-ppp@ucdavis.edu mailing list
Specification of
In this document, several words are used to signify the
of the specification. These words are often capitalized
This word, or the adjective "required", means that
definition is an absolute requirement of the specification
MUST
This phrase means that the definition is an
prohibition of the specification
Mathur & Lewis [Page 1]
RFC 1553 CIPX December 1993
This word, or the adjective "recommended", means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications should
understood and carefully weighed before choosing
different course
This word, or the adjective "optional", means that
item is one of an allowed set of alternatives.
implementation which does not include this option MUST
prepared to interoperate with another implementation
does include the option
Internetwork Packet Exchange (IPX) is a protocol defined by
Novell Corporation [1]. It is derived from the Internet
Protocol (IDP) protocol of the Xerox Network Systems (XNS)
of protocols. IPX is a datagram, connectionless protocol that
not require an acknowledgment for each packet sent. The
protocol corresponds to the network layer of the ISO model
Usually, there is a transport layer protocol above IPX. The
common transport protocol is the Netware Core Protocol (NCP),
is used for file server access. The Sequenced Packet
(SPX) is the reliable connection-based transport protocol
used by applications
The IPX packet consists of a 30 octet IPX header, usually
by the transport layer protocol header. The NCP header is 6
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
both IPX header compression strategies. These header
algorithms are based on those Van Jacobson described [2] for TCP/
packets
The first strategy is to compress only the IPX header.
compression algorithm can be used to compress any IPX packet
without affecting the transport protocol. This
compresses a 30 octet IPX header into a one to seven octet header
The second strategy is to compress the combined IPX and
headers. This algorithm compresses only NCP packets with NCP
of 0x2222 and 0x3333. This algorithm compresses a 36 octet NCP/
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
of header compression in conjunction with some type of
compression
Data compression technology takes many forms. Link bit
compression is a common approach over very low speed
links, normally performed by modems transparently. Transparent
stream compression is also offered in some DSUs, routers
bridges. Data compression can be provided using protocols such
CCITT V.42bis[3], MNP 5, Lempel-Ziv, or LAPB[4].
When using both header and data compression, the sequence
compression is important. When sending packets, data
MUST be done after header compression. Conversely when
packets, data decompression MUST be done before
decompression
IPX Compression
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
The IPX header diagram above is shown without the field
details. Consider each field of the IPX header separately, and
it typically changes
Historically, Novell has not used the Checksum field in the
Mathur & Lewis [Page 3]
RFC 1553 CIPX December 1993
header, and has required that this field be set to 0xFFFF. Since
Checksum field remains constant, it is clear that the value can
compressed
Where Checksums are implemented (not 0xFFFF), the Checksum MUST
included in the compressed packet. Recalculating the checksum
destroy the end-to-end reliability of the connection. Note
Checksums are now implemented in the Fault Tolerant Servers
For most links, the Packet Length can be determined from the
layer. There are cases in which the length cannot be determined
the MAC layer. For example, some hardware devices pad packets to
required minimum length. For links where it is not possible
determine the IPX packet length from the MAC layer, packet
needs to be included in the compressed packet
The Transport Control (Hops) field usually does not change
two end-points. For the purposes of compression, we will assume
it never changes, and will not examine this field when determining
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
endpoints known by a given source and destination address pair.
any specific IPX connection, the Destination and Source
fields are constant
Hence, the fields that may need to be included in the compressed
header are the Checksum and the Packet Length
While using this IPX header compression algorithm, packets can
lost. The loss of an Initial packet presents a problem. In
case, if the sender later tries to send a compressed packet,
receiving end cannot decompress the packet correctly
Sufficient information is not available in the IPX header
determine when a re-transmission has occured. For this reason, it
necessary that the sender of an Initial packet be guaranteed that
packet has been received. Therefore, we provide a mechanism
Confirmation of an Initial packet
NCP/IPX Header
Since most IPX packets are Netware Core Protocol packets (packet
17), compressing the NCP header will give us added performance.
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
The NCP header is 6 octets in length consisting of the
fields: NCP type, sequence number, connection number and task number
The NCP type field values that are currently defined are
1111 Create
2222 NCP request from
3333 NCP reply from file
5555 Destroy
7777 Burst Mode
9999 Server Busy
This NCP header compression algorithm only compresses packets
have a type field value of 0x2222 or 0x3333. If the NCP type
0x2222, this packet is a request from the client to the server
Conversely if the NCP type is 0x3333, this is a response from
server to the client. All other types of NCP packets are
compressed at the NCP level, but are compressed at the IPX level
The Create Connection (0x111), Destroy Connection (0x5555) and
Busy (0x9999) packets are not exchanged frequently enough to
special NCP compression. The Burst Mode (0x7777) packet is
below
The connection number is a constant for a given connection
The sequence number is increased by one for each new request.
the sequence number can be determined implicitly. The
Mathur & Lewis [Page 5]
RFC 1553 CIPX December 1993
increments the sequence number for each compressed packet it
for a connection
The task number can change unpredictably, although it might
constant for several packets. If the NCP task number is
from the last one for this connection, the NCP task number must
included
If the NCP packet is lost, it will be retransmitted through
normal transport layer mechanisms. The Initial NCP packet does
require confirmation, as a re-transmitted packet can be
identified. This is accomplished by comparing the sequence number
the packet to the sequence number of the previous packet. If
sequence number is not exactly one greater than the previous packet
a new Initial packet must be sent, although the same connection
may be used
In the event of compressed packet loss, the sequence number will
too small. When the IPX Checksum is present, the loss can
determined at the destination system by an incorrect checksum.
there is no checksum present, the loss is more likely to be
upon receiving a later retransmission
NCP Burst Mode
The burst mode protocol uses the NCP type value of 0x7777. This
of packet does not have the normal NCP header described above
Instead, it has a 36 octet burst header. The above NCP
compression algorithm should not be used to compress this packet
The IPX header in this packet is still compressible with the
header compression algorithm described
SPX
SPX packets are typically used by applications which
reliable service such as print servers. It is possible to apply
similar NCP/IPX technique to SPX/IPX packets. At this time,
have not described such a mechanism. The IPX header in
packet is still compressible with the IPX header
algorithm described
Compression
IPX compression should be negotiated by some means (eg. IPXCP
IPXWAN). Each end must negotiate the desired options, such as
maximum number of concurrent connections which will be
in each direction. Once IPX compression is negotiated, all
packets sent over that link have a CIPX header added to
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
is sent over the link. By including the CIPX header on
packet, we support the ability to run CIPX over various WAN
as if it were a normal IPX packet. It does not rely on any
link specific packet demultiplexing
Implementations of this compression protocol must maintain
and receive tables indicating the state of each connection.
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
each slot. The sending side (compressor) uses this information
determine the fields that have changed. The receiving
(decompressor) uses this information to reconstruct the
packet header
The CIPX packet header specifies the type of the packet and
options for that packet. The minimum CIPX header is one octet
length
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| | | | | | | | |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet
| | | | 0
| | | | 1
| | | | 3 Confirmed
| | | | 5
| | | | 7 Unconfirmed
| | | | 9
| | | | 11-15
| | | |
|__ |__ |__ |___________________ Packet Type Dependent
FLAGS
As can be seen above, the low order bits specify the packet type
All Compressed packets have a lowest bit of zero. The
packet types are odd numbers
Note that the Flags octet MUST NOT contain the value 0xFF.
is necessary to distinguish the CIPX flags octet from a normal
header with a 0xFFFF checksum field. It is important to be
Mathur & Lewis [Page 7]
RFC 1553 CIPX December 1993
to recognize a normal IPX header regardless of the state
compression. It is possible with some link layer protocols
as X.25 Permanent Virtual Circuits that one end of the link
fail and start sending regular IPX packets without the
header. CIPX implementations MUST recognize this situation
renegotiate the use of CIPX
Each packet type has associated flag bits, which are called
Type Dependent Flags. Different packet types have
Packet Type Dependent Flags. All bits that are reserved or
not specified must be set to zero
Since none of the packet types other than Compressed
uses any of the flag bits, the packet type field could easily
expanded. Any future expansion must ensure that at least one
the bits in the Flags octet remains zero so the value cannot
0xFF
Compressed
This type of packet does not contain a packet header (either 30
IPX, or 36 byte NCP). A slot number indicates to the receiver
saved header to use to formulate the original packet header
passing the packet up to IPX
Mathur & Lewis [Page 8]
RFC 1553 CIPX December 1993
________________________________ Slot
| 0 Assume same as last
| 1 Included in
|
| ____________________________
| | 0 Assume 0
| | 1 Included in
| |
| | ________________________
| | | 0 Determine from MAC
| | | 1 Included in
| | |
| | | ____________________ Task Number (NCP only
| | | | 0 Assume same as last
| | | | 1 Included in
| | | |
| | | | ________________ Reserved (Must be zero
| | | | | | |
| | | | | | | ____ Packet
| | | | | | | | 0 Compressed
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
working toward the lower order bits. Each of the fields is optional
but if present will be found in the same order in the
packet header
Slot
The slot number flag indicates the slot number field is included
the compressed packet. The slot number field is one octet in
and specifies the number of the slot which corresponds to the
packet header. Slots are numbered starting at zero and continue
the maximum number of slots minus one
By default, slot compression is disabled. If negotiated,
compression can be enabled for those slots which were created by
Unconfirmed Initial packet. When set to one (1), the slot
flag indicates the inclusion of the the slot number in the
packet. When set to zero (0), the slot number flag indicates
omission of the the slot number and specifies the use of the
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
account for all erroneous and discarded packets. When a
has been discarded, the slot number is indeterminate for
packets. The decompressor MUST discard all further
until a slot number is received
When set to one (1), the checksum flag indicates the
packet will include the 2 octet checksum. When set to zero (0),
this flag indicates the omission of the checksum and the
is to assume the checksum is 0xFFFF. Note that meaningful
must be included in the packet with the checksum flag set to one (1).
When set to one (1), the length flag indicates the inclusion of
IPX data length field in the compressed packet. When set to
(0), the length flag indicates the omission of the IPX data
field in the compressed packet
This is the Length field from the original IPX packet header.
specifies the length of IPX header and data in the packet prior
compression. It does not include the CIPX compression field such
flags, slot number, checksum, length field, or the NCP task number
Note that it is preferable to determine the length field from the
layer whenever possible, by subtracting the length of the
header fields and adding the length of the saved packet header
Since every octet is significant over lower speed WAN links,
optimization is used in the specification of the length. It can
specified as a one, two or three octet field. If the length is
the range 0 to 127, then it is specified as a one octet field.
the length is in the range 128 to 16383, it is specified as a
octet field in high to low order, with the first octet in the
128 to 191. Otherwise, if the length is greater than 16383,
first octet contains 192, and the second and third octets contain
full length. (This scheme is extensible to 8 octets, but
is not required in the IPX protocol suite.)
Mathur & Lewis [Page 10]
RFC 1553 CIPX December 1993
+-+-+-+-+-+-+-+-+
|0| length | length < 128
+-+-+-+-+-+-+-+-+
ONE OCTET LENGTH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| length | length < 16384
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TWO OCTET LENGTH
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 0 0| length | length < 65535
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
THREE OCTET LENGTH
Task
When set to one (1), the NCP task number flag indicates the NCP
number is included in the compressed packet (see NCP/IPX
above). When set to zero (0), the NCP task number flag indicates
omission of the NCP task number in the compressed packet. When
NCP task number is not included in the compressed packet, we use
same NCP task number as that of last packet
Based upon the bits set in the flags octet, optional portions
included in the compressed IPX header. The minimum compressed
header contains only the Flags octet. All fields in the original
header have been compressed out of the header. The
compressed IPX header can include up to 7 octets, the Flags, Slot
Checksum (2 octets), and Length (3 octets) fields, or 8 octets if
NCP Task Number is included. The minimum and maximum compressed
packets are shown below. Header fields are one octet in
except where noted
Mathur & Lewis [Page 11]
RFC 1553 CIPX December 1993
+--------+---------
| Flags | DATA ...
| 0x00 |
+--------+---------
MINIMUM COMPRESSED IPX
+--------+--------+---------+---------+---------
| Flags | Slot |Checksum | Length | DATA ...
| 0xE0 | Number |2 octets |3 octets |
+--------+--------+---------+---------+---------
MAXIMUM COMPRESSED IPX
+--------+--------+---------+---------+--------+---------
| Flags | Slot |Checksum | Length |NCP Task| DATA ...
| 0xF0 | Number |2 octets |3 octets | Number |
+--------+--------+---------+---------+--------+---------
MAXIMUM COMPRESSED NCP/IPX
Regular
The Regular packet type designates an IPX packet for which
compression is desired. This type of packet is sent when a
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
| | | | 1
| | | |
|__ |__ |__ |___________________ Reserved (must be zero
The Regular packet is rarely sent. Usually, the Regular packet
sent when there is not enough memory for the overhead of a
compression slot. Also, this type is included for future
changes to the IPX protocol which defeat the effectiveness
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
Mathur & Lewis [Page 12]
RFC 1553 CIPX December 1993
hard to determine for specific protocols. Various methods
as hold-down and least-recently-used timers are currently
used
On receipt, the 1 octet header is simply removed and the
passed up to IPX
The entire IPX packet follows the single Flags octet. Note for
Regular Packet (not compressed or uncompressed), the slot
field is not included
Confirmed Initial
The Confirmed Initial packet type is used by the compressor to
the decompressor of the original packet header which will be used
subsequent compression, and to request Confirmation. The high
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
| | | | 3 Confirmed
| | | |
|__ |__ |__ |___________________ 0 IPX
1-15
This type of packet is sent to inform the receiver to associate
IPX packet header with a slot number. This packet is sent each
a different header format is sent for a given slot, or when
sender has not received a Confirmation Packet from the receiver
The Flags octet lower 4 bits indicate the Confirmed Initial
packet type. The high order 4 bits are reserved for expansion
support additional protocols. The Flags octet is always followed
the Slot Number and an ID field. The ID field is one octet
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
uniquely identify a header. In practice, the ID octet can be
number which is unique for a "reasonably long period" of time.
reasonably long period is a function of transmission speed,
trip delays, and network load. There must be very little chance
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
packet until confirmation. When a new packet with the same
header is to be sent, another Confirmed Initial packet
be sent using the same slot, the same ID, and the new
data
When a new packet with a different IPX header is to be sent,
may be sent using a slot which has not received confirmation
A Confirmed Initial packet is sent with the same slot,
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
Initial packet has been sent but not confirmed
+---------+---------+---------+-/ /-+----------
| Flags | Slot | ID | IPX | DATA ...
| 0x03 | Number | | Header |
+---------+---------+---------+-/ /-+----------
CONFIRMED INITIAL
Note that a Confirmed Initial header is followed by a complete
packet
Confirm
The Confirm packet type is used by the decompressor to tell
compressor that it has received the Confirmed Initial packet
When the compressor receives this, it can start sending
frames
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet
| | | | 5
| | | |
|__ |__ |__ |___________________ Reserved (must be zero
A Confirm Packet is exactly 3 octets in length. It consists of
Mathur & Lewis [Page 14]
RFC 1553 CIPX December 1993
Flags, Slot Number and ID fields. The Slot Number field contains
number of the slot which is being acknowledged. The ID
contains the ID of the Confirmed Initial Packet which is
acknowledged
+---------+---------+----------+
| Flags | Slot | ID |
| 0x05 | Number | |
+---------+---------+----------+
CONFIRM
Unconfirmed Initial
The Unconfirmed Initial packet type is used by the compressor
inform the decompressor of the original packet header which will
used for subsequent compression while not requesting confirmation
After sending an Unconfirmed Initial packet, the compressor
immediately send Compressed packets without confirmation
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet
| | | | 7 Unconfirmed
| | | |
|__ |__ |__ |___________________ 0 NCP
1-15
This type of packet is sent to inform the receiver to associate
IPX packet header with a slot number. This packet is sent each
a different header format is sent for a given slot
The Flags octet lower 4 bits indicate the Unconfirmed Initial
packet type. The high order 4 bits are reserved for expansion
support additional protocols. The Flags octet is always followed
the Slot Number
+---------+---------+-/ /-+-/ /-+---------
| Flags | Slot | IPX | NCP |
| 0x07 | Number | Header | Header | DATA ...
+---------+---------+-/ /-+-/ /-+---------
Mathur & Lewis [Page 15]
RFC 1553 CIPX December 1993
UNCONFIRMED INITIAL
Note that an Unconfirmed Initial header is followed by a complete
packet
Reject
The Reject packet type is used by the decompressor to tell
compressor that it has received a CIPX packet with a header which
does not support. This is provided to regulate future extensions
CIPX
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet
| | | | 9
| | | |
|__ |__ |__ |___________________ Reserved (must be zero
A Reject Packet is exactly 3 octets in length. It consists of
Flags, Slot Number and Rejected Flags fields
The Slot Number field contains the number of the slot of the
which is being rejected. Since the actual packet type may be
or misunderstood, this field actually contains the second octet
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
rejected. The packet type field is left untouched. Any flags
are correctly recognized should be cleared. The remaining
indicate specific features that are being rejected. This
should be sufficient for implementations to adjust the use of
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
IPX header and forwarded without CIPX processing to
appropriate routines. Under no circumstances should a
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
Compression Negotiation over PPP
For PPP links [5], the use of header compression can be negotiated
IPXCP [6]. By default, no compression is enabled
The IPX-Compression-Protocol Configuration Option is used to
the ability to receive compressed packets. Each end of the link
separately request this option if bi-directional compression
desired
The PPP Protocol field is set to the same value as the usual
packets, and all IPX packets sent over the link MUST conform to
compressed format
A summary of the IPX-Compression-Protocol Configuration Option
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3
6
IPX-Compression-
0002 (hex) for Telebit Compressed IPX headers (CIPX).
Max-Slot-
The Max-Slot-Id field is one octet and indicates the
Mathur & Lewis [Page 17]
RFC 1553 CIPX December 1993
slot identifier. This is one less than the actual number
slots; the slot identifier has values from zero to Max-Slot
Id
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
ability for the PPP link level to indicate an error
reception to the decompression module. Synchronization
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
that only the Compressed Packet type is an even number
with the lowest order bit of zero. All other packet types
odd values with a lowest order bit of one. The reason for
assignment was to make it possible to determine the
Packet type by examining only one bit. This make it
to use all the other 7 bits to indicate status in
Compressed Packet. The 7 bits are composed of the upper 4
which are permanently defined to indicate packet
flags, plus bits 1-3 which are otherwise part of the
Type. The upper 4 bits are defined above. The redefinition
bits 1-3 of the Compressed Packet type is left for
expansion
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| | | | | | | | 0 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |___ Packet
| | | | | | | 0 Compressed
| | | | | | |
| | | | |___|___|_______ Redefined
| | | |
|___|___|___|___________________ Compressed Packet
By default, this feature in not enabled and this flag
set to zero. When this flag is set to one, it
Mathur & Lewis [Page 18]
RFC 1553 CIPX December 1993
the desire to use this feature
Compression Negotiation over IPXWAN
"IPXWAN" is the protocol Novell uses to exchange necessary
to router information prior to exchanging standard IPX
information and traffic over WAN datalinks [7]. To negotiate
Telebit compression option, we use Novell's allocated option
for CIPX (00) in the IPXWAN timer request/response packet
The Timer Request packet contains the following Telebit
option
WOption Number 80 - Define compression
WAccept Option 01 - 0=No, 1=Yes, 3=N/
WOption Data Len 00 03 - Length of
WOption Data 00 - Telebit's compression (CIPX
WOption Data XX - Compression
WOption Data NN - Compression
Where the WOption Data fields are
00 Telebit's compression option described in
document (CIPX).
XX Compression options as defined below
0x01 Compress slot ID when
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
option is supported and NO if the option is not supported. A
Response must respond with only one header compression type set
YES
The Timer Response packet that accepts the option will look
this
WOption Number 80 - Define compression
WAccept Option 01 - 0=No, 1=Yes, 3=N/
WOption Data Len 00 03 - Length of
WOption Data 00 - Telebit's compression (CIPX
WOption Data XX - Compression
WOption Data NN - Compression
Mathur & Lewis [Page 19]
RFC 1553 CIPX December 1993
Where the WOption Data fields are
00 Telebit's compression option described in
document (CIPX).
XX Compression options as defined below
0x01 Compress slot ID when
0x02 Redefine Compressed Packet type bits 1-3.
NN The negotiated # of slots (The lower of each side'
requested number of slots
IPX packets (except of course IPXWAN packets) are not sent over
link until the IPXWAN negotiations are completed. Once
negotiations are completed, regular IPX packets can be sent over
link
If both ends of the link agree on the compression options, then
IPX packets are sent using the specified options. If either end
the link does not accept a compression option, then this
option will not be used. Compression will be done using
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
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
Timer Request
To be clear, IPXWAN is used to set up a symmetrical compression link
Compression is configured identically in both directions. Each
will use the same number of slots and same compression options.
is illegal for link ends to use different number of slots
different options
IPX Compression
The performance of this algorithm will depend on the number of
connections and the number of slots negotiated. If the number
slots is greater than the number of connections, the hit rate
be very high giving a very high compression ratio. The
also depends on the average size of the IPX packets. If the
size of packets is small, then compression will result in a
noticeable performance improvement
Mathur & Lewis [Page 20]
RFC 1553 CIPX December 1993
avg_data_len + uncomp_header_
Compression ratio = ----------------------------------
avg_data_len + avg_comp_header_
Where 'avg_data_len' is the average length of data in the IPX packet
and 'uncomp_head_len' is the uncompressed header length which
fixed at 30 octets. Where 'avg_comp_header_len' is the
length of the compressed IPX header. The length of the
compressed IPX header is 1 octet. The length of the
compressed NCP/IPX header is 8 octets (including the NCP
number), but since no implementation yet sends packets with a
greater than 16K, 7 octets is the commonly encountered maximum
Perhaps a reasonable 'avg_comp_header_len' is 2, assuming
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
send packets of up to 4096 octets. The minimum length of the data
an IPX packet is 1 octet. Within the normal distribution of
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
IPX provides some security features, which are fully applicable
CIPX. CIPX does not significantly alter the basic security of IPX
Mathur & Lewis [Page 21]
RFC 1553 CIPX December 1993
[1] Novell Inc., "IPX Router Specification", September 1992,
Number: 107-000029-001
[2] Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed
Links", RFC 1144, February 1990
[3] CCITT Recommendation V.42bis Error Correcting Procedures for
using Error Correction
[4] ISO 7776, Information Processing Systems - Data Communication -
High Level Data Link Control Procedures - Description of the X.25
LAPB-Compatible DTE Data Link
[5] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1548,
December 1993
[6] Simpson, W. A., "The PPP Internet Packet Exchange
Protocol (IPXCP)", RFC 1552, December 1993
[7] Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]",
RFC 1551, December 1993
This compression algorithm incorporates many ideas from the
Jacobson TCP/IP header compression algorithm
Michael Allen from Novell provided a lot of valuable feedback in
design of this algorithm. David Piscitello from Bellcore and
Del Vecchio at Shiva Corp. made several good suggestions.
Simpson was very helpful in driving PPP, and specifically IPXCP,
the standards course
Chair's
Fred
Advanced Computer
315 Bollay
Santa Barbara, California 93117
EMail: fbaker@acc.
Mathur & Lewis [Page 22]
RFC 1553 CIPX December 1993
Authors'
Saroop
Telebit Corp
1315 Chesapeake
Sunnyvale, CA 94089-1100
EMail: mathur@telebit.
Mark S.
Telebit Corp
1315 Chesapeake
Sunnyvale, CA 94089-1100
EMail: Mark.S.Lewis@telebit.
Mathur & Lewis [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
