rfc1553.txt

RFC 的详细文档！

   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.