4. Grouping packets into packet streams

This section explains how packets MAY be grouped together into packet streams for compression. To achieve the best compression rates, packets SHOULD be grouped together such that packets in the same packet stream have similar headers. If this grouping fails, header compression performance will be bad, since the compression algorithm can rarely utilize the existing context for the packet stream and full headers must be sent frequently.

Grouping is done by the compressor. A compressor may use whatever criterion it finds appropriate to group packets into packet streams. To determine what packet stream a packet belongs to, a compressor MAY

a) examine the compressible chain of subheaders (see section 7),

b) examine the contents of an upper layer protocol header that follows the compressible chain of subheaders, for example ICMP headers, DVMRP headers, or tunneled IPX headers,

c) use information obtained from a resource manager, for example if a resource manager requests compression for a particular packet stream and provides a way to identify packets belonging to that packet stream,



d) use any other relevant information, for example if routes flap and the hop limit (TTL) field in a packet stream changes frequently between n and n+k, a compressor may choose to group the packets into two different packet streams.

A compressor is also free not to group packets into packet streams for compression, letting some packets keep their regular headers and passing them through unmodified.

As long as the rules for when to send full headers for a non-TCP packet stream are followed and subheaders are compressed as specified in this document, the decompressor is able to reconstruct a compressed header correctly regardless of how packets are grouped into packet streams.

4.1 Guidelines for grouping packets

In this section we give OPTIONAL guidelines for how a compressor may group packets into packet streams for compression.

Defining fields

  The defining fields of a header should be present and identical in
  all packets belonging to the same packet stream.  These fields are
  marked DEF in section 7. The defining fields include the flow
  label, source and destination addresses of IP headers, final
  destination address in routing headers, the next header fields
  (for IPv6), the protocol field (IPv4), port numbers (UDP and TCP),
  and the SPI in authentication and encryption headers.

Fragmented packets

  Fragmented and unfragmented packets should never be grouped
  together in the same packet stream. The Identification field of
  the Fragment header or IPv4 header should not be used to identify
  the packet stream. If it was, the first fragment of a new packet
  would cause a compression slow-start.

  No field after a Fragment Header, or an IPv4 header for a
  fragment, should be used for grouping purposes.

Upper protocol identification

  The first next header field identifying a header not described in
  section 7 should be used for identifying packet streams, i.e., all
  packets with the same DEF fields and the same upper protocol
  should be grouped together.



TTL field (Hop Limit field)

  A sophisticated implementation might monitor the TTL (Hop Limit)
  field and if it changes frequently use it as a DEF field. This can
  occur when there are frequent route flaps so that packets traverse
  different paths through the internet.

Traffic Class field (IPv6), Type of Service field (IPv4)

  It is possible that the Traffic Class field of the IPv6 header and
  the Type of Service of the IPv4 header will change frequently
  between packets with otherwise identical DEF fields.  A
  sophisticated implementation should watch out for this and be
  prepared to use these fields as defining fields.

When IP packets are tunneled they are encapsulated with an additional IP header at the tunnel entry point and then sent to the tunnel endpoint. To group such packets into packet streams, the inner headers should also be examined to determine the packet stream. If this is not done, full headers will be sent each time the headers of the inner IP packet changes. So when a packet is tunneled, the identifying fields of the inner subheaders should be considered in addition to the identifying fields of the initial IP header.

An implementation can use other fields for identification than the ones described here. If too many fields are used for identification, performance might suffer because more CIDs will be used and the wrong CIDs might be reused when new flows need CIDs. If too few fields are used for identification, performance might suffer because there are too frequent changes to the context.

We stress that these guidelines are educated guesses. When IPv6 is widely deployed and IPv6 traffic can be analyzed, we might find that other grouping algorithms perform better. We also stress that if the grouping fails, the result will be bad performance but not incorrect decompression. The decompressor can do its task regardless of how the grouping algorithm works.