IP Payload Compression Protocol (ippcp)
---------------------------------------
Charter
Last Modified: 09/16/1999
Current Status: Concluded Working Group
Chair(s):
Naganand Doraswamy <naganand@baynetworks.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion:ippcp@external.cisco.com
To Subscribe: mailer@cisco.com
In Body: subscribe/unsubscribe ippcp [email_addr] in body
Archive: ftp://ftp-eng.cisco.com/ippcp/ippcp
Description of Working Group:
Lossless data compression has commonly been deployed in layers below IP
(PPP being one example). However, the anticipated deployment of
higher-layer encryption protocols (e.g., IPSec) threatens to reduce the
effectiveness of lower-layer compression techniques since encrypted
data cannot be compressed. The IP Payload Compression Protocol Working
Group will develop protocol specifications that make it possible to
perform lossless compression on individual payloads before the payload
is processed by a protocol that encrypts it. These specifications will
allow for compression operations to be performed prior to the
encryption of a payload by such protocols as IPSec.
The Working Group will focus on the compression of independent payloads
(i.e., independent datagrams) in a stateless manner. By stateless, we
mean that decompression of a received packet does not rely on correct
reception or correct ordering of previous packets.
The immediate problem the Working Group will address is the development
of a payload compression protocol for use in conjunction with IPSec.
The working group will develop its specifications to support both IPv4
and IPv6. Although the primary motivation for this WG is the need to
compress packets when IPSec is used, the WG will develop an
architecture that does not preclude its use with other potential
protocols or the absence of IPSec.
The working group will identify and document the mechanisms that allow
two communicating parties to negotiate the use of compression as well
as the compression format to be employed. The Working Group will
consider defining extensions to ISAKMP to support the negotiation of
compression parameters. Use of ISAKMP as the immediate effort shall not
preclude compression in the absence of IPsec. Alternate negotiation
mechanisms (or even static negotiation), if appropriate, shall be
identified and extended as needed to accommodate the use of payload
compression functionality. Since compression will be negotiated,
existing implementations of IP will interoperate with implementations
that support compression.
The output of this WG will consist of a base architectural document
that provides the framework for how compression will be done (i.e.,
defines the compression "shim"), together with one or more documents
giving specific compression algorithms and formats. The architectural
document will describe how different compression algorithms can be
negotiated and supported, but the documenting of specific compression
algorithms will be done elsewhere (i.e., in standalone documents). A
registration mechanism for various compression formats will be
specified as part of the base protocol. If possible, an existing
registration mechanism for compression formats shall be used (e.g.,
Compression Control Protocol options of PPP).
Goals and Milestones:
JUL 97 Submit Internet-Draft on Base Architecture for IP Payload
Compression Protocol
JUL 97 Solicit drafts of compressed data formats from working
group
AUG 97 Meet in Munich to discuss submitted drafts
AUG 97 Revise drafts to reflect working group discussion/inputs
OCT 97 Submit IP Payload Compression Protocol architectural
document to the IESG for consideration as a Proposed
Standard.
OCT 97 Submit specific compression transform document(s) to the
IESG for consideration as a Proposed Standard or as
Informational RFC.
OCT 97 Submit document definining mechanism for using ISAKMP to
negotiate compression formats to the IESG for consideration
as Proposed Standard.
DEC 97 Meet in Washington, DC to discuss implementation issues
relating to IP Payload Compression Protocol, compressed
data format drafts, and possible future work of the group
JAN 98 AD review of WG. Revise charter or close group down.
Internet-Drafts:
No Current Internet-Drafts.
Request For Comments:
RFC Stat Published Title
------- -- ----------- ------------------------------------
RFC2393 PS DEC 98 IP Payload Compression Protocol (IPComp)
RFC2394 I DEC 98 IP Payload Compression Using DEFLATE
RFC2395 I DEC 98 IP Payload Compression Using LZS