rfc1974.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Friend & Simpson             Informational                      [Page 5]

RFC 1974                        Stac LZS                     August 1996


      been received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.

      On reception, the Identifier field of the Reset-Request is copied
      into the Identifier field of the Reset-Ack packet.

   Data

      The Data field contains the two octet History Number of the
      compression history that is to be reset, most significant octet
      first.  This History Number value is 1 when no history number is
      present.

2.4.  Data Expansion

   The maximum expansion of Stac LZS is 12.5%.

   A Maximum Receive Unit (MRU) MAY be negotiated that is 12.5% larger
   than the size of a normal packet.  Then, packets can always be sent
   compressed regardless of expansion.

   When the expansion plus compression header exceeds the size of the
   peer's MRU for the link, the PPP packet MUST be sent without
   compression, in the original PPP packet form with the "native" PPP
   Protocol ID number.  The transmitter MUST reset the affected history.

   If it is detected that most packets are expanding (for example, due
   to the use of already compressed data), then the transmitter SHOULD
   stop sending compressed packets, and reset the appropriate history.
   Data compression MAY be resumed on this data link later.

2.5.  Packet Format

   A summary of the Stac LZS packet format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |       (History Number*)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        (Check Value*)         |       Compressed Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    * Note: these fields are variable length fields as described below.







Friend & Simpson             Informational                      [Page 6]

RFC 1974                        Stac LZS                     August 1996


   2.5.1.  PPP Protocol

      The PPP Protocol field is a 2 octet field described in the Point-
      to-Point Protocol Encapsulation [1].

      When the Stac LZS compression protocol is successfully negotiated
      by the PPP Compression Control Protocol [2], the value is 00FD hex
      or 00FB hex as described in section 2.  This value MAY be
      compressed when Protocol-Field-Compression is negotiated.

   2.5.2.  History Number

      The history number field comprises 0, 1, or 2 octets.

      The number of the compression history which was used, ranging from
      2 to the negotiated History Count.  By default a History Count of
      value 1 is supported and this field is not present.

      If the negotiated History Count is less than 2, this field is
      removed.  There is no need for the field when no history is kept,
      or only a single history is kept.

      If the negotiated History Count is 2 or more, but less than
      256,this field is 1 octet.  If 256 or more histories are
      negotiated, this field is 2 octets, most significant octet first.

   2.5.3.  Check Value

      The check value field comprises 0, 1, or 2 octets.  By default,
      sequence number check is added to the packet (the field comprises
      1 octet).

      2.5.3.1.  LCB

         A simple one octet Longitudinal Check Byte (LCB) MAY be used,
         after successful negotiation of the LCB option.  The LCB is the
         Exclusive-OR of FF(hex) and each octet of the uncompressed
         datagram (prior to the compression operation).  On receipt, the
         receiver computes the Exclusive-OR of FF(hex) and each octet of
         the decompressed packet.  If this value does not match the
         received LCB, then a receive failure for that history has
         occurred.  The receive failure is handled according to the
         history synchronization procedure in section 2.5.4.

      2.5.3.2.  CRC

         A two octet Cyclic Redundancy Check (CRC) MAY be used, instead
         of the LCB, after successful negotiation of the CRC option.



Friend & Simpson             Informational                      [Page 7]

RFC 1974                        Stac LZS                     August 1996


         The transmitter MUST initialize the CRC value to FFFF(hex) at
         the beginning of each packet.  The CRC computation is based on
         the HDLC FCS-16 polynomial:

            x**16 + x**12 + x**5 + 1

         The ones complement of the CRC is transmitted least significant
         octet first, which contains the coefficient of the highest
         term. On receipt, the receiver initializes the CRC to FFFF
         (hex), and computes the CRC based on the formula above for each
         octet of the decompressed packet.  If the received CRC value
         does not match the transmitted CRC value, then a receive
         failure for that history has occurred.  The receive failure is
         handled according to the history synchronization procedure in
         section 2.5.4.

      2.5.3.3.  Sequence Number

         A one octet Sequence Number MAY be used, instead of a LCB or
         CRC, after successful negotiation of the Sequence Number
         option.  After CCP has reached the open state, the transmitter
         MUST set the value of the sequence number field (the sequence
         number of the packet) to "1" and increment modulo 256 on
         successive packets that contain data fields.  The sequence
         number is relative to the history number used.

         After CCP has reached the open state, the receiver MUST set its
         internal reference value of the next expected sequence number
         (the sequence number of next packet to be received) to "1".

         After a packet is received, the receiver MUST set the value of
         its internal reference value of the next expected sequence
         number for that history to the value of the sequence number
         field of the received packet plus 1 modulo 256.

         If the sequence number of the received packet is not equal to
         the internal reference value of the expected sequence number
         for the same history, a receive failure for that history has
         occurred.  The receiver MUST silently discard the out of order
         packet, and handle the failure according to the history
         synchronization procedure in section 2.5.4.

         The sequence number MUST NOT be reset by the transmitter when a
         packet containing a Reset-Req is received. The receiver MUST
         always maintain its sequence number references for all
         supported histories.





Friend & Simpson             Informational                      [Page 8]

RFC 1974                        Stac LZS                     August 1996


      2.5.3.3.1  History Synchronization with Sequence Numbers Example

      Compressing Sender                Decompressing Receiver
      ....                              ....
      send seq 101     ----------->     recv seq 101
                                        is 101 == 101?  Ok.
                                        forward packet for processing
                                        set internal reference to 102

      send seq 102     ----------->     recv seq 102
                                        is 102 == 102?  Ok.
                                        forward packet for processing
                                        set internal reference to 103

      send seq 103     ------X          (packet lost)

      send seq 104     ----------->     recv seq 104
                                        is 104 == 103?  Send reset req!
                                        silently discard packet
                                        set internal reference to 105

      (packet lost)        X-------     send reset request (ID=200)
                                        post-increment the identifier.

      send seq 105     ----------->     recv seq 105
                                        is 105 == 105?  Ok.
                                        was reset ack received?  No!
                                        silently discard packet
                                        set internal reference to 106

                       <-----------     send reset request again(ID=200)
                                        (e.g. reset-ack time out)

      send seq 106     ------X          (packet lost)

      recv reset req   <-----------
      (after line delay)
         (ID=200)

      reset compression
         history
      send reset ack   ----------->     recv reset ack (ID=200)
         (ID=200)

      send seq 107     ----------->     recv seq 107
                                        is 107 == 106?  Send reset req!
                                        silently discard packet
                                        set internal reference to 108



Friend & Simpson             Informational                      [Page 9]

RFC 1974                        Stac LZS                     August 1996


      recv reset req   <-----------     send reset request (ID=201)
         (ID=201)                       post-increment the identifier.

      send seq 108     ----------->     recv seq 108
                                        is 108 == 108?  Ok.
                                        was reset ack received?  No!
                                        silently discard packet
                                        set internal reference to 109

      send seq 109     ----------->     recv seq 109
                                        is 109 == 109?  Ok.
                                        was reset ack received?  No!
                                        silently discard packet
                                        set internal reference to 110

      reset compression
         history
      send reset ack   ----------->     recv reset ack (ID=201)
         (ID=201)

      send seq 110     ----------->     recv seq 110
                                        is 110 == 110?  Ok.
                                        forward packet for processing
                                        set internal reference to 111

      send seq 111     ----------->     recv seq 111
                                        is 111 == 111?  Ok.
                                        forward packet for processing
                                        set internal reference to 112
      ....                              ....

   2.5.4.  History Synchronization Procedure

      On receipt, if Sequence Number one (1) follows any other number
      than zero (0), or is otherwise out of sequence, or the LCB or CRC
      is invalid, a CCP Reset-Request MUST be sent, containing the two
      octet History Number (most significant octet first, and which is
      the value 1 when no History Number is present), with a CCP
      Identifier.  Identifiers are incremented on each occurrence of an
      out of sequence packet.

      Upon receipt of the Reset-Request, the transmitter MUST reset the
      affected compression history, and transmit a CCP Reset-Ack packet
      with the Identifier field and data (history number) field set to
      the corresponding values of the Reset-Request.  However, the
      Sequence Number (if implemented) is not reset.





Friend & Simpson             Informational                     [Page 10]