NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 03-Nov-97
Chair(s):
Naganand Doraswamy <naganand@baynetworks.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Thomas Narten <narten@raleigh.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 defining 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:
· IP Payload Compression Protocol (IPComp)
· IP Payload Compression Using LZS
· IP Payload Compression Using DEFLATE
No Request For Comments
Minutes of the IP Payload Compression Protocol (IPPCP) Working Group
Chair: Naganand Doraswamy
Area Director: Thomas Narten
Mailing address: ippcp@external.cisco.com
The agenda for the meeting was:
I. Status - Naganand
II. Architecture/Protocol draft- Avram Shacham
III. LZS draft- Bob Monsour
IV. Next Steps- Naganand
I. Status
The architecture draft went through the working group last call with minor editorial changes. There were no major changes to necessitate the need for another last call. Thomas Narten had some comments which need to be incorported into the draft.
There was some discussion as to how to deal with getting new transform ID's from IANA. It was decided that we will follow the same model as the IPsec working group for getting new transform ID's.
The working group agreed that we should not mandate any compression algorithm. The working group also decided not to define tunnel mode for the protocol.
II. Architecture/Protocol Draft
Avram discussed the changes in the draft before it went to the last call. The latest draft is draft-ietf-ippcp-protocol-03.txt.
Cisco's prototype implementation was discussed. The prototype has the new header format done. ISAKMP negotiation is in progress.
Avram suggested using some kind of guidelines for the drafts describing new algorithms. These include
· Getting a transform ID < 64 for manual setup
· Getting a trasnform ID for DOI and define parameters if any
· Guidelines on non-expansion
- threshold
- compressibility
It was also decided not to restrict the CPI values 0-63 only for manual setup but also use it for ISAKMP for well known algorithms.
III. LZS Compression Draft
Bob discussed the changes to the draft and agreed to incorporate the
Guidelines in the draft. This draft will become an informational RFC. Bob also discussed licensing issues for LZS both hardware and software.
IV. Next Steps
It was agreed that interoperability is most important. IPPCP will be tested in the next IPsec workshop. The architecture draft will move forward after review from IESG.
There was also encouragement for people to write drafts for other compression algorithms.
None Received