GPCOMP
HTT Consulting
Oak Park
MI
48237
rgm@labs.htt-consult.com
Huawei
7453 Hickory Hill
Saline
MI
48176
USA
shares@ndzh.com
Alcatel-Lucent
Room 2D-144, 600 Mountain Avenue
Murray Hill
NJ
07974
USA
igor.faynberg@alcatel-lucent.com
Nokia
Room 2D-144, 600 Mountain Avenue
Murray Hill
NJ
07974
USA
huilan.lu@nokia.com
FreeLance
yrz@anche.no
Security Area
RFC
Request for Comments
I-D
Internet-Draft
This document describes a protocol intended to provide lossless
compression for use within any datagram. It is particularly
intended for use in encrypted datagrams where lower-level
compression is ineffective.
Generic payload compression is a protocol to reduce the size of
most datagrams. This protocol will increase the overall
communication performance by compressing the datagrams, provided
the participating devices have sufficient computation power,
through either CPU capacity or a compression coprocessor, and the
communication is over constrained links.
Generic payload compression is especially useful when encryption is
applied to datagrams. Encrypting a datagram causes the data to be
random in nature, rendering compression at lower protocol layers
ineffective.
This document defines the Generic payload compression protocol
(GPComp), a GPComp packet structure, the GPComp Association (GPCA),
and several methods to negotiate the GPCA.
Other documents shall specify how a specific compression algorithm
can be used with the Generic payload compression protocol. Such
algorithms are beyond the scope of this document.
This document draws heavily on IPCOMP .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.
The Generic Payload Compression Protocol Association. This
is the collection of attributes and values that define how
GPComp operates.
The compression processing has two phases: compressing of outbound
datagrams ("compression") and decompressing of inbound datagrams
("decompression"). The compression processing MUST be lossless,
ensuring that the datagram, after being compressed and
decompressed, is identical to the original datagram.
Each datagram is compressed and decompressed by itself without any
relation to other datagrams ("stateless compression"), as datagrams
may arrive out of order or not arrive at all.
Processing of inbound datagrams MUST support both compressed and
non-compressed datagrams, in order to meet the non-expansion policy
requirements, as defined in .
Compression is applied to a single datagram. The size of a
compressed payload, generated by the compression algorithm, MUST be
in whole octet units.
As compression is optional for each datagram associated within the
GPCA, an identification mechanism is REQUIRED for each datagram.
Minimally this can be a single option bit within the datagram's
header (if it has one). Alternatively, the GPComp header, defined
in , is inserted immediately
preceding the compressed payload. The receiving side MUST be able
to distinguish between compressed and uncompressed payloads.
The receiver MUST be able to recognize the condition of no
compression for the case where there is no datagram header option
flag for compression and only the presense of the GPComp header
indicates a compressed payload. In this case, the payload itself
has no indication that GPComp is enabled for the payload, but there
is nothing to decompress. The receiving process has to be able to
identify the payload as lacking the GPComp header and act
appropriately. Thus it is best if there is a datagram header
compression flag (for example in SSE ) and the GPComp header is not even
used.
If the total size of a compressed payload and the GPComp header (if
present) is not smaller than the size of the original payload, the
datagram MUST be sent in the original non-compressed form. To
clarify: If an datagram is sent non-compressed, no GPComp header is
added to the datagram. This policy ensures saving the
decompression processing cycles and avoiding incurring datagram
fragmentation if the expanded datagram is larger than the MTU. It
does present a potential conundrum to
the receiver.
Small datagrams are likely to expand as a result of compression.
Therefore, a numeric threshold should be applied before
compression, where datagrams of size smaller than the threshold are
sent in the original form without attempting compression. The
numeric threshold is implementation dependent.
A datagram payload with compressed content tends not to compress
any further. The previously compressed payload may be the result
of external processes, such as compression applied by an upper
layer in the communication stack, or by an off-line compression
utility. An adaptive algorithm should be implemented to avoid the
performance hit. For example, if the compression of i consecutive
IP datagrams of an GPCA fails, the next several datagrams, say k,
are sent without attempting compression. If then the next j
datagrams also fail to compress, a larger number of datagrams, say
k+n, are sent without attempting compression. Once a datagram is
compressed successfully, the normal process of IPComp restarts.
Such an adaptive algorithm, including all the related thresholds,
is implementation dependent.
During the processing of the payload, the compression algorithm MAY
periodically apply a test to determine the compressibility of the
processed data, similar to the requirements of . The nature of the test is algorithm dependent.
Once the compression algorithm detects that the data is
non-compressible, the algorithm SHOULD stop processing the data,
and the payload is sent in the original non- compressed form.
The compressed datagram structure for GPComp can be implied or
explicit. The implied structure is used with datagrams that have a
header field with option flags and a length field or
end-of-datagram identifier. The explicit structure uses the GPComp
header.
The implied structure takes one option flag bit in the datagram
header. This bit is ONE if that datagram is compressed or ZERO if
not compressed. The compression algorithm is specified within the
GPCA. The implied structure can be used within SSE.
The GPComp header is used for datagrams that do not have a defined
header with an options field, or do not have an available bit in
the header to flag compression status. IPFIX and NETCONF use such a
datagram.
The GPComp header is identical to the IPComp header . This is for done for simplicity sake. Although
it is possible to design a GPComp header of only 2 bytes, this
would break the typical 32 bit word alignment in Internet Protocol
headers. In many uses, the Next Header field will be NULL; this is
set by the GPCA.
The use of GPComp and its options (e.g. compression algorithm)
should be part of the communication start up process. Although
GPComp can be manually set up, this may result in a lack of agility
in compression algorithm selection. That is, only one algorithm is
used and cannot easily be changed. Thus manual set up for GPComp
should be limited to testing needs.
An application may use any internal set up mechanism for
negotiating GPComp. However, as compression is frequently used in
conjunction with encryption, the application may call a Key
Management Protocol (KMP) and request that the KMP set up GPComp.
The GPCA is a data structure that controls the operation of GPComp.
The content of the GPCA is application dependent but it will
always include the Compression Parameter Index (CPI) as defined in
IPCOMP.
At set up, and application may call IKEv2 .
This may be to enable ESP in Transport Mode or SSE for secure communications. It the same
time, IKE may be instructed to negotiate IPCOMP, but the
application will use the negotiated IPCOMP CPI for GPComp.
At set up, and application may call HIPv2
or HIP-DEX . This may be to
enable ESP in BEET Mode or SSE for
secure communications.
HIP does not currently include a negotiation for compression. Both
this GPComp and an IPCOMP negotiation can be added by assigning a
HIP parameter value for a Compression Transform that is higher than
ESP. A value of 4111 can be used for this purpose. The
negotiation will mirror the ESP transform negotiation and be
carried in the R1 and I2 payloads as is ESP transform. This
parameter and negotiation may be explicitly expanded here at in a
later revision.
IANA is requested to assign a HIP parameter value for the
Compression Transform. This parameter value should be higher than
ESP and SSE. A value of 4111 is recommended.
Data Compression Procedures for Data Circuit Terminating
Equipment (DCE) Using Error Correction Procedures
CCITT