rfc3051.txt

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


RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001


   compressed data and differentiate compressed data from padding.  Any
   bits or bytes beyond the FLUSH codeword within the compressed payload
   are to be considered padding.

   The size of a compressed payload MUST be in whole octet units.

3. Decompression Process

   The decompression of datagrams is performed by a function called the
   Decoder.

3.1 Compressed Datagram

   If the received datagram is compressed, the receiver MUST reset the
   decoder dictionary prior to processing the datagram.  This ensures
   that each datagram can be decoded independently of any other datagram
   in the event datagrams are lost or received out of order.  Beginning
   with the decoder dictionary in the initial state, as specified in
   clause 7.5.2 of [V44], the receiver decodes the payload data field of
   the datagram according to the procedure specified in clause 6.4 of
   [V44].

3.2 Original Uncompressed Datagram

   If the received datagram is not compressed, the receiver does not
   perform compression decoding and passes the payload data field of the
   datagram unaltered to the next protocol layer.

4. IPComp Association (IPCA) Parameters

   IKE [RFC2409] MAY be used to negotiate the use of the LZJH
   compression algorithm to establish an IPCA, as defined in [RFC2393].

4.1 Transform ID

   The value of the LZJH Transform ID is IPCOMP_LZJH.  This value is
   used to negotiate the use of the LZJH data compression algorithm
   using IKE.

4.2 Security Association Attributes

   There are no other parameters required for the negotiation of the
   LZJH compression algorithm using IKE.

4.3 Manual configuration

   The CPI value IPCOMP_LZJH is used for manually configured IPComp
   Compression Associations.



Heath & Border               Informational                      [Page 5]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001


4.4 Minimum packet size threshold

   As stated in [RFC2393], small packets may not compress well.
   Informal tests using the LZJH algorithm on internet web pages and e-
   mail files show that the average payload size that typically produces
   expanded data is approximately 50 bytes.  Thus, implementations may
   prefer not to attempt to compress payloads of approximately 50 bytes
   or smaller.

4.5 Compressibility test

   The LZJH algorithm, as described in [V44], is easily modified to
   incorporate an adaptive compressibility test, as referenced in
   [RFC2393].  Annex B of [V44] specifies the mechanism for including
   such a test in LZJH.

5. Security Considerations

   This document does not add any further security considerations to
   those discussed in [RFC2393].

6. IANA Considerations

   This document does not introduce any new name spaces.  The value of
   IPCOMP_LZJH is assigned from the IPsec IPCOMP transform identifier
   space defined in [RFC2407].  IANA has assigned a value of 4 for this
   purpose.

7. Acknowledgements

   This document is modeled upon [RFC2395].

8. References

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

   [LZ78]    Lempel, A., and Ziv, J., "Compression of Individual
             Sequences via Variable Rate Coding", IEEE Transactions On
             Information Theory, Vol. IT-24, No. 5, Sep 1978.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2393] Shacham, A., "IP Payload Compression Protocol (IPComp)",
             RFC 2393, December 1998.




Heath & Border               Informational                      [Page 6]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001


   [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
             LZS", RFC 2395, December 1998.

   [RFC2407] Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November, 1998.

   [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC
             2409, November 1998.

   [V44]     ITU Telecommunication Standardization Sector (ITU-T)
             Recommendation V.44 "Data Compression Procedures", November
             2000.

9. Authors' Addresses

   Jeff Heath
   Hughes Network Systems
   10450 Pacific Center Ct.
   San Diego, CA  92121

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


   John Border
   Hughes Network Systems
   11717 Exploration Lane
   Germantown, MD  20876

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


















Heath & Border               Informational                      [Page 7]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001


10. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Heath & Border               Informational                      [Page 8]