rfc1553.txt

RFC 的详细文档！

      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