datatracker.ietf.org
Sign in
Version 5.9.0, 2014-12-18
Report a bug

Compressing IPX Headers Over WAN Media (CIPX)
RFC 1553

Document type: RFC - Historic (December 1993; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 1553 (Historic)
Responsible AD: (None)
Send notices to: No addresses provided

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

[include full document text]