rfc1974.txt

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

         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]

RFC 1974                        Stac LZS                     August 1996


      For each packet that generates a receive failure, the receiver
      MUST increment the Identifier and transmit a CCP Reset-Request.
      For re-transmissions of existing receive failures, the Identifier
      MUST NOT be incremented.

      After transmitting the Reset-Request packet, the receiver MUST
      continue silently discarding valid compressed packets for the
      corresponding history, until the correct CCP Reset-Ack Identifier
      (corresponding to the Reset-Request) for that History Number is
      received.  Note that if sequence numbers are used, the receiver
      MUST process the sequence number of a received packet according to
      the procedures in section 2.5.4.

   2.5.5.  Compressed Data

      The data field MUST contain only one datagram in compressed form.
      The length of this field is always an integer number of octets.
      There MUST BE only one end marker per block of compressed data.

      The form of the data field is one block of compressed data as
      defined in 3.2 of X3.241-1994, and is repeated here for
      informational purposes ONLY.

   <Compressed Stream> := [<Compressed String>] <End Marker>
   <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
   <Raw Byte> := <b><b><b><b><b><b><b><b>          (8-bit byte)
   <Compressed Bytes> := <Offset> <Length>

   <Offset> := 1 <b><b><b><b><b><b><b> |           (7-bit offset)
               0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
   <End Marker> := 110000000

<b> := 1 | 0

   <Length> :=
   00        = 2     1111 0110      = 14
   01        = 3     1111 0111      = 15
   10        = 4     1111 1000      = 16
   1100      = 5     1111 1001      = 17
   1101      = 6     1111 1010      = 18
   1110      = 7     1111 1011      = 19
   1111 0000 = 8     1111 1100      = 20
   1111 0001 = 9     1111 1101      = 21
   1111 0010 = 10    1111 1110      = 22
   1111 0011 = 11    1111 1111 0000 = 23
   1111 0100 = 12    1111 1111 0001 = 24
   1111 0101 = 13     ...




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


3.  Sending Compressed Datagrams

   The reliable and efficient transport of datagrams on the data link
   depends on the following processes.

3.1.  Transmitter Process

   When a network datagram is received, it is assigned to a particular
   history buffer and processed according to ANSI X3.241-1994 to form
   compressed data.  Prior to the compression operation, if a Reset-
   Request is outstanding for the history buffer to be used or if the
   negotiated history count for this data link is 0, the history buffer
   is cleared.

   Uncompressed data MUST be sent (in the original PPP packet form with
   the "native" PPP Protocol ID number) if compression causes enough
   expansion to cause the data compression datagram size to exceed the
   Information field's MRU.  In this case, since the compressor has
   modified the history buffer before sending an uncompressed datagram,
   the history buffer MUST be cleared before the next datagram is
   processed.

   The output of the compression operation is placed in the information
   field of the datagram.  If the sequence number field is present
   according the value of the check mode field, the sequence number
   counter for the applicable history number MUST be incremented and its
   value placed in the sequence number field.  If the LCB field is
   present according the value of the check mode field, the LCB value
   MUST be computed as specified in section 2.5.3.1. and the resultant
   value placed in the LCB field.  If the CRC field is present according
   the value of the check mode field, the CRC value MUST be computed as
   specified in section 2.5.3.2.  and the resultant value placed in the
   LCB field.  Upon reception of a CCP Reset-Request packet, the
   transmitting compressor MUST be cleared to an initial state, which
   includes clearing the history buffer.  In addition to the reset of
   the compressor, a CCP Reset-Ack packet MUST be transmitted.  The data
   field of this packet MUST be filled with the corresponding two octet
   history number, most significant octet first.

3.2.  Receiver Process

   If a CCP Reset-Request packet is received, the local compression
   engine MUST be signaled that a Reset-Request has been received for
   the history number specified in the data field.  If a CCP Reset-Ack
   packet is received, any outstanding receive failure for the specified
   history MUST be cleared.  If no receive failure is outstanding, and
   the sequence number field is present, its value is checked.  If a
   receive failure has occurred, it MUST be handled according to the



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


   history resynchronization mechanism described below, and the
   remainder of the datagram is discarded.

   If no receive failure is detected, the data is assigned to the
   indicated decompression history buffer and the compressed data block
   MUST be decompressed according to ANSI X3.241-1994.  If the LCB or
   CRC fields are present on the received datagram, an LCB or CRC for
   the uncompressed data MUST be computed and checked against the
   received LCB or CRC according to sections 2.5.3.1. or 2.5.3.2.,
   respectively.  If a receive failure has occurred, it MUST be handled
   according to the History Resynchronization Mechanism described in
   section 3.4.

   If a CCP Reset-Ack packet is received, the receiving decompressor's
   corresponding history MAY be reset to an initial state.  (However,
   due to the characteristics of the Stac LZS algorithm, a decompressor
   history reset is not required).  After reset, any compressed or
   uncompressed data contained in the packet is processed.

   On the occurrence of a receive failure, an implementation MUST
   transmit a CCP Reset-Request packet with the data field containing
   the two octet history number (most significant octet first) matching
   the history that had the failure.  Once a receive failure has
   occurred, the data in any subsequent packets received for that
   history MUST be discarded until a CCP Reset-Ack packet containing a
   valid Identifier matching the Identifier that was sent with the last
   CCP Reset-Request packet is received.  It is the responsibility of
   the receiver to ensure the reliability of the Reset-Request/Ack
   mechanism.  This may require the transmission of additional CCP
   Reset-Request packets before a CCP Reset-Ack packet is received.

3.3.  History Maintenance

   The History Count field determines the number of history buffers to
   be maintained for the compression protocol.  For example, each
   history buffer could represent a separate logical connection between
   the data compression peers.  When maintaining a history, the peers
   MUST use link error detection and signaling to ensure that both the
   compressor and decompressor copies of each history buffer are always
   identical.

   Setting the History Count field to the value "0" indicates that the
   compression is to be on a connectionless basis.  In this case, a
   single history buffer is used and MUST be cleared at the beginning of
   every datagram.

   When the History Count field is set to the value "1", a single
   history buffer is maintained by each of the data compression peers.



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


   (A single logical connection.)

   When the History Count field is set to a value greater than "1",
   separate history buffers, error detection states, and signaling
   states are maintained by the decompressing entity for each history.
   The compressing peer may transmit data on any number of separate
   histories, up to the value of the History Count field.

3.4.  History Resynchronization Mechanism

   The Stac LZS protocol utilizes CCP Reset-Request/Reset-Ack mechanism
   in order to provide a mechanism for indicating a receiver failure in
   one direction of a compressed link without affecting traffic in the
   other direction.  A receive failure is determined using the LCB, CRC,
   or sequence number mechanisms, according to the value of the check
   mode field.