NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
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 Using LZS
· IP Payload Compression Protocol (IPComp)
· IP Payload Compression Protocol Architecture
No Request For Comments
IPPCP - IETF/Munich August 13, 1:00pm
Chaired by Naganand Dorswamy
Reported by Roy Pereira
The IPPCP working group met for the first time in Munich. There were approximately 35 attendees. The agenda was to discuss the charter and resolve some architecture and protocol issues.
The discussions on the charter did not change the charter that was approved by the IESG. The primary goal of the working group is to define a compression protocol. The primary goal is to make it work in the context of IPsec. However, the working group will define the protocol so that it is generic enough to work even when IPsec is not being used. As discussed in the charter, we will support both manual and dynamic negotiation of compression parameters such as algorithm. This working group does not deal with issues of compression at the transport layer.
I. Three Presentations
Bob Monsour
Bob presented the combined architecture draft: draft-ietf-ippcp-arch-00.txt which raised the following issues
1. Should we support per session based compression?
2. Should we support stateful or stateless compression?
3. Should we mandate whether compression should be used if it increases the size of payload and whether we should include the compression header in that case?
4. If used with a key mgmt protocol such as ISAKMP, should we negotiate compression as an attribute or as a protocol?
There were two proposals for performing compression, and this presentation highlighted the advantages and disadvantages of the two approaches- ip-in-ip or a separate protocol header. These issues have been discussed in the architecture draft as well.
Matt Thomas
Matt Thomas presented his draft although the protocol header that he presented was different than what was specified in his draft. The protocol header was then changed during the course of the meeting. The final protocol header that will be proposed to the working group is shown below.
+-------------+-------------+-----------------------------+
| Next Header | Flags | Compression Parameter Index |
+-------------+-------------+-----------------------------+
Avram Shacham
-------------
Avram presented his draft draft-ietf-ippcp-ipcomp-00.txt. He discussed when and why it makes sense to compress packets before performing compression. It was mentioned during the presentation that it makes more sense to compress over slow links.
Performance increase of 1.7 for 28.8k
Performance decrease of 0.7 for 10M
There were questions asked about whether it makes sense to compress packets even on fast links if the encryption algorithm is slow. There is no data to make any statements on this as most of the tests were performed using LZS compression and DES and MD5 and encryption and hash.
URL of presentation: www.tgv.cisco.com/public/shacham/ipcomp.ppt
II. Resolutions
The following were some of the things the working group agreed on.
1. IPCOMP must be done before IPSec
2. The compression should be stateless
3. The compression, if desired, should be on the granularity of a session.
4. If the compression expands the packet, then compression SHOULD not be performed and in that case the compression header SHOULD not be sent in the packet.
5. Compression should be implemented as a separate protocol.
III. Open Issues
1. Architecture document must state that all algorithm documents must state thresholds for whether compression should be performed.
2. We need to finalize the IPCOMP protocol (i.e., bits of the wire).
3. Location of IPCOMP within IPv6 must be defined in architecture document.
4. Should a CPI failure send ICMP error messages?
5. Should we have static SA that are defined by predefined public CPI values?
6. Should IPCOMP be a "MUST used" before AH/ESP/frag/hop-by-hop
7. Should we mandate any one particular algorithm as mandatory to implement?
IV. Next Steps
If possible, compress the protocol document and the architecture document into one and publish this document as soon as possible. This will enable us to decide on the header format so that people can implement this protocol. The open issues need to be addressed in this document.
It was a common consensus that this working group should be done with its commitments by the Washington IETF.