rfc1553.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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 [e-mail] 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