rfc1974.txt

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

   Reset-Requests and Reset-Acks are specific to the history number of
   the packet containing them.

   Reset-Request/Reset-Ack history synchronization signaling is provided
   to recover from a loss of synchronization between peers, especially
   in unreliable transport layers.  As with all compression algorithms,
   the decompressor can not recover from dropped, erroneous, or mis-
   ordered datagrams, and will propagate errors catastrophically until
   both peers are reset to an initial state.

   The Stac LZS protocol provides a means to detect these error
   conditions: LCB or CRC for erroneous datagrams, and sequence number
   for dropped or mis-ordered datagrams.  There is a means for
   correcting a loss of synchronization: clear both the failing
   compression and decompression histories, and follow the transmitter
   and receiver processes in sections 3.1. and 3.2.

4.  Configuration Option Format

Description

      The CCP Stac LZS Configuration Option negotiates the use of
      Stac LZS on the link.  By ultimate disagreement, no compression is
      used.

      All implementations must support the default values.








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


   A summary of the Stac LZS Configuration Option 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        History Count          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Check Mode  |
   +-+-+-+-+-+-+-+-+


   Type

      17

   Length

      5

   History Count

      The History Count field is two octets, most significant octet
      first, and specifies the maximum number of Compression Histories.

      The value 0 indicates that the implementation expects the peer to
      clear the Compression History at the beginning of every packet.

      The value 1 is the default value, and is used to indicate that
      only one history is maintained.

      Other valid values range from 2 to 65535.  The peer is not
      required to send as many histories as the implementation indicates
      that it can accept.  However, it should be noted that resources
      are allocated in each peer to support the number of negotiated
      histories in this field.

   Check Mode

      The Check Mode field indicates support of LCB, CRC or Sequence
      checking, and other future extensions to this standard.  This
      field comprises 2 sub-fields, and is considered to be bit-mapped.
      The 3 least significant bits comprise 5 mutually exclusive values.
      The upper 5 bits are all "Reserved" bit locations must be set to
      "0" to allow for future backward-compatible extensions to this
      standard.





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


      For compatibility, Sequence Numbers MUST be implemented; the other
      four check modes MAY be implemented.

Defined values:

         0    None             (MAY be implemented; however, MUST
                                implement history count of zero)
         1    LCB              (MAY be implemented)
         2    CRC              (MAY be implemented)
         3    Sequence Number  (MUST be implemented)
         4    Extended Mode    (MAY be implemented)

          0       1        2        3     4     5     6     7
      +-------+-------+----------+-----+-----+-----+-----+-----+
      |    LCB/CRC/Seq#/Ext'd    | Res | Res | Res | Res | Res |
      +-------+-------+----------+-----+-----+-----+-----+-----+

5. Definition of Extended Mode

   When Check Mode 4 (Extended Mode) is successfully negotiated, the
   packet format is different from the format described above. The
   Extended Mode format is described below.  Extended Mode only supports
   a history count of 1.

5.1. Extended Mode Packet Format

    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          |A|B|C|D| Coherency Count       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Compressed Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PPP Protocol

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

      When a compression protocol is successfully negotiated by
      the PPP Compression Control Protocol [2], the value is hex 00FD.
      Protocol-Field-Compression MUST NOT be used on this value when
      extended mode is negotiated on the link, even if Protocol-Field-
      Compression was successfully negotiated before data compression.







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


   Bit A - PACKET_FLUSHED

      This bit indicates that the history buffer has just been reset
      before this packet was generated.  Thus, this packet can ALWAYS
      be decompressed because it is not based on any previous history.
      This bit is typically sent to inform the peer that it has reset
      its history buffer and that the peer can accept this packet
      and re-synchronize.

   Bit B

      This bit is not used with Stac LZS compression.

   Bit C - PACKET_COMPRESSED

      This bit is used to indicate that the packet is compressed.  A
      value of 0 indicates uncompressed data, and a value of 1 indicates
      compressed data.

   Bit D

      This bit is not used with Stac LZS compression.

   Coherency Count

      The coherency count is used to assure that the packets are sent in
      proper order and that no packet has been dropped.  This count is
      initialized to the value 0x000, and is always increased by 1 after
      each PPP packet is sent.  When all bits are 1, the count returns
      to 0.

      The coherency count is 12 bits so the decompressor must handle the
      rollover case.

   Compressed Data

      The compressed data begins with the protocol field.  For example,
      an IP packet may contain 0021 followed by an IP header. The
      compressor will first try to compress the 0021 protocol field and
      then move on to the IP header.

      Protocol-Field-Compression MUST NOT be used on this value when
      extended mode is negotiated on the link, even if Protocol-Field-
      Compression was successfully negotiated before data compression.

      Zero deletion/insertion described in section 2.2 MUST NOT be
      performed when extended mode is negotiated.




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


5.2. Extended Mode Transmitter Process

   When a network datagram is received, it is processed according to
   ANSI X3.241-1994 to form compressed data.  If a CCP Reset-Request has
   been received from the decompressor, the compressor must clear its
   history buffer before sending the next packet.

   Uncompressed data MUST be sent if the compression operation causes
   the compressed datagram to expand.  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 uncompressed data is placed in the
   information field of the datagram, and Bit-A MUST be set (indicating
   the history was cleared) and Bit-C MUST be clear (indicating
   uncompressed data) in the current packet's header. The value of the
   coherency counter is placed in the coherency count field and then the
   coherency counter is incremented.

   If the compression operation does not cause the compressed datagram
   to expand and if a received Reset-Request is outstanding, then the
   output of the compression operation is placed in the information
   field of the datagram, and Bit-A MUST be set (indicating the history
   was cleared) and Bit-C MUST be set (indicating compressed data) in
   the current packet's header. The value of the coherency counter is
   placed in the coherency count field and then the coherency counter is
   incremented.

   If the compression operation does not cause the compressed datagram
   to expand and there is not a Reset-Request outstanding, then the
   output of the compression operation is placed in the information
   field of the datagram, and Bit-A MUST be clear (indicating the
   history was not cleared) and Bit-C MUST be set (indicating compressed
   data) in the current packet's header. The value of the coherency
   counter is placed in the coherency count field and then the coherency
   counter is incremented.

   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, the PACKET_FLUSHED bit MUST be set in the header of the
   next transmitted data packet.

5.3. Extended Mode Receiver Process

   When a data compression datagram is received from the peer, Bit-A and
   Bit-C MUST be checked.  Prior to the decompression operation, if
   Bit-A is set, then the coherency count MUST be resynchronized to the
   received value in the coherency count field of the received packet,



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


   and 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, depending on the state of Bit-C.

   Prior to the decompression operation, if Bit-C is clear (indicating
   uncompressed data), then the decompression history buffer must not be
   modified and the decompressor is not involved with deencapsulation.
   If Bit-C is set (indicating compressed data) then the received packet
   is decompressed according to ANSI X3.241-1994.

   If the received packet is corrupt, then a Reset-Request is sent and
   this packet is discarded.  If the received packet contains an
   incorrect coherency count, a Reset-Request is sent and this packet is
   discarded.

5.4. Extended Mode Synchronization

   Packets may be lost during transfer. If the decompressor maintained
   coherency count does not match the coherency count received in the
   compressed packet or if the decompressor detects that a received
   packet is corrupted, the decompressor drops the packet and sends a
   CCP Reset-Request packet. The compressor on receiving this packet
   resets the history buffer and sets the PACKET_FLUSHED bit in the next
   frame it sends. The decompressor on receiving a packet with its
   PACKET_FLUSHED bit set, resets its history buffer and sets its
   coherency count to the one shipped by the compressor in that packet.

   Thus synchronization is achieved without a Reset-Ack packet.

Security Considerations

   Security issues are not discussed in this memo.

















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


References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, Daydreamer, July 1994.

   [2]   Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
         1962, July 1996.

   [3]   Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
         Data Compression", IEEE Transactions On Information Theory,
         Vol. IT-23, No. 3, May 1977.

   [4]   Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
         1994.

Chair's Address

   The working group can be contacted via the current chair:

      Karl F. Fox
      Ascend Communications
      3518 Riverside Dr., Suite 101
      Columbus, Ohio  43221

      [phone]

      EMail: [e-mail]

Authors' Addresses

   Questions about this memo can also be directed to:

      Robert Friend
      Stac Technology
      12636 High Bluff Drive
      San Diego, CA  92130
      [phone]
      EMail: [e-mail]


      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071
      [e-mail]
          [e-mail] (preferred)




Friend & Simpson             Informational                     [Page 20]