One document matched: draft-moskowitz-gpcomp-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-moskowitz-gpcomp-00.txt" ipr="trust200902">

<front>
<title abbrev="Generic Payload Compression Protocol">GPCOMP</title>
	<author fullname="Robert Moskowitz" initials="R." surname="Moskowitz" >
	<organization>HTT Consulting</organization>
	<address>
	<postal> 
	  <street> </street>
	  <city>Oak Park</city>
	  <region>MI</region>
	  <code>48237</code> 
	</postal>
	<email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Susan Hares" initials="S." surname="Hares">
	<organization>Huawei</organization>
	<address>
	<postal> 
	  <street>7453 Hickory Hill</street>
	  <city>Saline</city>
	  <region>MI</region>
	  <code>48176</code>
	  <country>USA</country>
	</postal>
	<email>shares@ndzh.com</email>
	</address>
	</author>
	<author fullname="Igor Faynberg" initials="I." surname="Faynberg">
	<organization>Alcatel-Lucent</organization>
	<address>
	<postal> 
	  <street>Room 2D-144, 600 Mountain Avenue </street>
	  <city>Murray Hill</city>
	  <region>NJ</region>
	  <code>07974</code>
	  <country>USA</country>
	</postal>
	<email> igor.faynberg@alcatel-lucent.com</email>
	</address>
	</author>
	<author fullname="Huilan Lu" initials="H." surname="Lu">
	<organization>Nokia</organization>
	<address>
	<postal> 
	  <street>Room 2D-144, 600 Mountain Avenue </street>
	  <city>Murray Hill</city>
	  <region>NJ</region>
	  <code>07974</code>
	  <country>USA</country>
	</postal>
	<email>huilan.lu@nokia.com</email>
	</address>
	</author>
	<author fullname="Pierpaolo Giacomin" initials="P." surname="Giacomin">
	<organization>FreeLance</organization>
	<address>
	<email>yrz@anche.no</email>
	</address>
	</author>
<date year="2016" />
   <area>Security Area</area>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
<abstract>
<t>
	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.
</t>
</abstract>
</front>
<middle>   
<section title="Introduction">
<t> 
	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. 
</t> 
<t> 
	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.
</t> 
<t> 
	This document defines the Generic payload compression protocol 
	(GPComp), a GPComp packet structure, the GPComp Association (GPCA), 
	and several methods to negotiate the GPCA.
</t> 
<t> 
	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.
</t> 
<t> 
	This document draws heavily on IPCOMP <xref target="RFC3173"/>.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
	<section title="Requirements Terminology">
	<t>
		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 <xref target="RFC2119">RFC 2119</xref>.
	</t>
	</section>
	<section title="Definitions">
	<t>
		<list style="hanging">
		<t hangText="GPCA:">
			The Generic Payload Compression Protocol Association.  This 
			is the collection of attributes and values that define how 
			GPComp operates.
		</t>
		</list>
	</t>
	</section>
</section>
<section anchor="Process" title="Compression Process">
<t>
	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.
</t>
<t>
	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.
</t>
<t>
	Processing of inbound datagrams MUST support both compressed and 
	non-compressed datagrams, in order to meet the non-expansion policy 
	requirements, as defined in <xref target="Non-Expansion" />.
</t>
<section title="Compressed Payload">
<t>
	Compression is applied to a single datagram. The size of a 
	compressed payload, generated by the compression algorithm, MUST be 
	in whole octet units.
</t>
<t>
	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 <xref target="GPComp-header" />, is inserted immediately 
	preceding the compressed payload. The receiving side MUST be able 
	to distinguish between compressed and uncompressed payloads.
</t>
</section>
<section anchor="Conundrum" title="Uncompressing Conundrum">
<t>
	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 <xref 
	target="I-D.moskowitz-sse" />) and the GPComp header is not even 
	used.
</t>
</section>
<section anchor="Non-Expansion" title="Non-Expansion Policy">
<t>
	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 <xref target="Conundrum" /> to 
	the receiver.
</t>
<t>
	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.
</t>
<t>
	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.
</t>
<t>
	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 <xref 
	target="V42BIS" />.  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.
</t>
</section>
</section>
<section title="Compressed Datagram Structure">
<t>
	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.
</t>
<section title="Implied Structure">
<t>
	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.
</t>
</section>
<section anchor="GPComp-header" title="GPComp header for Explicit Structure">
<t>
	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 <xref 
	target="RFC7011"/> and NETCONF <xref target="RFC6536"/> use such a 
	datagram.
</t>
<t>
	The GPComp header is identical to the IPComp header <xref 
	target="RFC3173"/>.  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.
</t>
</section>
</section>
<section title="Negotiating GPComp">
<t>
	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.
</t>
<t>
	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.
</t>
<section title="The GPCA">
<t>
	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.
</t>
</section>
<section title="Using IKEv2">
<t>
	At set up, and application may call IKEv2 <xref target="RFC7296"/>. 
	This may be to enable ESP in Transport Mode <xref 
	target="RFC4303"/> 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. 
</t>
</section>
<section title="Using HIP">
<t>
	At set up, and application may call HIPv2 <xref target="RFC7401"/> 
	or HIP-DEX <xref target="I-D.ietf-hip-dex" />. This may be to 
	enable ESP in BEET Mode <xref target="RFC7402"/> or SSE for 
	secure communications.
</t>
<t>
	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.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
	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.
</t>
</section>
<section title="Security Considerations">
<t>
	TBD 
</t>
</section>
<section title="Contributors">
<t>
	TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
	<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
	<?rfc include="reference.RFC.3173.xml"?>
	<?rfc include="reference.RFC.4303.xml"?>
	<?rfc include="reference.RFC.6536.xml"?>
	<?rfc include="reference.RFC.7011.xml"?>
	<?rfc include="reference.RFC.7296.xml"?>
	<?rfc include="reference.RFC.7401.xml"?>
	<?rfc include="reference.RFC.7402.xml"?>
	<?rfc include="reference.I-D.ietf-hip-dex.xml"?>
	<?rfc include="reference.I-D.moskowitz-sse.xml"?>
	<reference anchor="V42BIS">
		<front>
		<title>Data Compression Procedures for Data Circuit Terminating 
		Equipment (DCE) Using Error Correction Procedures</title>
		<author><organization>CCITT</organization></author>
		<date month="January" year="1990" />
		</front>
		<seriesInfo name="Recommendation" value="V.42 bis" />
	</reference>
</references>
</back>
</rfc>