rfc1967.txt

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

      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 processed according to process
      mode field and C/U bit.

      If the C/U bit is set to "1", a single octet containing the value
      0x00 MUST be appended to the data field and the resulting
      compressed data block MUST be decompressed according to ANSI
      X3.241-1994.  If the LCB field is present on the received
      datagram, an LCB for the uncompressed data MUST be computed and
      checked against the received LCB according to section 2.1.  If a
      receive failure has occurred, it MUST be handled according to the
      History Resynchronization Mechanism described below.

      If the C/U bit is set to "0" and the process mode field is set to
      the value Process-Uncompressed ("1"), the specified decompression
      history buffer MUST be updated with the received uncompressed
      data.

      If the C/U bit is set to "0" and process mode field is set to the
      value None ("0"), the specified decompression history buffer MUST
      NOT be modified.

      If the R-A bit is set to "1", the receiving decompressor MAY be
      reset to an initial state.  (However, due to the characteristics
      of the Stac LZS algorithm, a decompressor 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 packet with the R-R bit set to "1" (a Reset-Request)
      and with the history number matching the history that had the
      failure.  The data field may be present if data is waiting to be
      transported for that history, or the R-R bit may be set in a
      packet transmitted without sequence number, data, or LCB fields.
      Once a receive failure has occurred, the data in any subsequent
      packets received for that history MUST be discarded until a packet
      containing a Reset-Ack is received.  It is the responsibility of
      the receiver to ensure the reliability of the reset request-
      acknowledge mechanism.  This may require the transmission of an
      additional Reset-Request before a Reset-Ack will be 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,



Schneider & Friend           Informational                     [Page 13]

RFC 1967                        LZS-DCP                      August 1996


      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.  The compressing entity MUST set the
      R-A bit on all outgoing datagrams.

      When the History Count field is set to the value "1", a single
      history buffer is maintained by each of the data compression
      peers. (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.  Anti-Expansion Mechanism

      When one or more histories are negotiated and the Process Mode
      field is set to None ("0"), there are 2 options on how to handle
      packets that expand:

         1) Send the expanded data and keep the history, thus allowing
            loss of current bandwidth but preserving future bandwidth on
            the link.
         2) Send the uncompressed data and clear the history, thus
            conserving current bandwidth, but allowing possible loss of
            future bandwidth on the link.

      When 1 or more histories are negotiated and the Process Mode field
      is set to Process-Uncompressed ("1"), there is an additional
      option:

         3) Send the uncompressed data and do not clear the compression
            history; the decompressor will update its history, thus
            conserving the current bandwidth and future bandwidth on the
            link.

3.5.  History Resynchronization Mechanism

      The DCP-Header includes R-R (Reset-Request) and R-A (Reset-Ack)
      bits 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



Schneider & Friend           Informational                     [Page 14]

RFC 1967                        LZS-DCP                      August 1996


      using the sequence number and/or LCB mechanism, according to the
      value of the check mode field.

      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 LZS-DCP protocol provides a means to detect these error
      conditions: LCB 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

   The LZS-DCP Configuration Option negotiates the use of LZS-DCP on the
   link.  By default or ultimate disagreement, no compression is used.
   This Configuration Option is used in CCP, and can be used in other
   negotiation mechanisms [2].

   All implementations MUST support the default values.

   A summary of the LZS-DCP 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  | Process Mode  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      23

   Length

      6



Schneider & Friend           Informational                     [Page 15]

RFC 1967                        LZS-DCP                      August 1996


   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.
      If this value is selected, the transmitter MUST set the Reset-Ack
      bit of every packet that contains compressed data.

      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 indicates support of LCB and/or Sequence checking.
      The use of check mode None (0) MUST NOT be used for history counts
      greater than zero.

         0    None
         1    LCB
         2    Sequence Number
         3    Sequence Number + LCB (default)

   Process Mode

      The Process Mode specifies how uncompressed packets are handled.
      A value of None (0) indicates that uncompressed packets are not
      processed by the decompressor.  A value of Process-Uncompressed

      (1) indicates that uncompressed packets are processed by the
      decompressor to update the history.

         0    None (default)
         1    Process-Uncompressed

Security Considerations

   Security issues are not discussed in this memo.






Schneider & Friend           Informational                     [Page 16]

RFC 1967                        LZS-DCP                      August 1996


Acknowledgments

   This document is based on, and uses much of the text of [5].

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, June 1996.

   [3]    Lempel, A., and J. Ziv, "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.

   [5]    Friend, R., and W. Simpson, "PPP Stac LZS Compression
          Protocol", RFC 1974, August 1996.

   [6]    Motorola Information Systems Group, "Data Compression Protocol
          (DCP) Proposal", TR-30.1 ad hoc contribution (email
          reflector), September 21, 1995.

   [7]    ANSI X3.241-1994, "American National Standard Data Compression
          Method, Adaptive Coding with Sliding Window of Information
          Interchange".

Chair's Address

   The working group can be contacted via the current chair:

   Karl Fox
   Ascend Communications
   3518 Riverside Drive, Suite 101
   Columbus, Ohio 43221

   EMail: [e-mail]











Schneider & Friend           Informational                     [Page 17]

RFC 1967                        LZS-DCP                      August 1996


Authors' Addresses

   Questions about this memo can also be directed to:

   Kevin Schneider
   Adtran, Inc.
   901 Explorer Blvd.
   Huntsville, AL 25806

   Phone: [phone]
   EMail: [e-mail]


   Robert Friend
   Stac Technology
   12636 High Bluff Drive
   San Diego, CA 92130-2093

   Phone: [phone]
   EMail: [e-mail]































Schneider & Friend           Informational                     [Page 18]