Skip to main content

5. Size Issues

5.1. Context Identifiers

Context identifiers can be 8 or 16 bits long. Their size is not relevant for finding the context. An 8-bit CID with value two and a 16-bit CID with value two are equivalent.

The CID spaces for TCP and non-TCP are separate, so a TCP CID and a non-TCP CID never identify the same context. Even if they have the same value. This doubles the available CID space while using the same number of bits for CIDs. It is always possible to tell whether a full or compressed header is for a TCP or non-TCP packet, so no mixups can occur.

Non-TCP compressed headers encode the size of the CID using one bit in the second octet of the compressed header. The 8-bit CID allows a minimum compressed header size of 2 octets for non-TCP packets, the CID uses the first octet and the size bit and the 6-bit Generation value fit in the second octet.

For TCP the only available CID size is 8 bits as in [RFC-1144]. 8 bits is probably sufficient as TCP connections are always point-to- point.

The 16 bit CID size may not be needed for point-to-point links; it is intended for use on multi-access links where a larger CID space may be needed for efficient selection of CIDs.

The major difficulty with multi-access links is that several compressors share the CID space of a decompressor. CIDs can no longer be selected independently by the compressors as collisions may occur. This problem may be resolved by letting the decompressors have a separate CID space for each compressor. Having separate CID spaces requires that decompressors can identify which compressor sent the compressed packet, perhaps by utilizing link-layer information as to who sent the link-layer frame. If such information is not available, all compressors on the multi-access link may be enumerated, automatically or otherwise, and supply their number as part of the CID. This latter method requires a large CID space.

5.2. Size of the context

The size of the context SHOULD be limited to simplify implementation of compressor and decompressor, and put a limit on their memory requirements. However, there is no upper limit on the size of an IPv6 header as the chain of extension headers can be arbitrarily long. This is a problem as the context is essentially a stored header.

The configurable parameter MAX_HEADER (see section 14) represents the maximum size of the context, expressed as the maximum sized header that can be stored as context. When a header is larger than MAX_HEADER, only part of it is stored as context. An implementation MUST NOT compress more than the initial MAX_HEADER octets of a header. An implementation MUST NOT partially compress a subheader.

Thus, the part of the header that is stored as context and is compressed is the longest initial sequence of entire subheaders that is not larger than MAX_HEADER octets.

5.3. Size of full headers

It is desirable to avoid increasing the size of packets with full headers beyond their original size, as their size may be optimized for the MTU of the link. Since we assume that the link layer implementation provides the length of packets, we can use the length fields in full headers to pass the values of the CID and the generation to the decompressor.

This requires that the link-layer must not add padding to the payload, at least not padding that can be delivered to the destination link user. It is also required that no extra padding is added after UDP data or in tunneled packets. This allows values of length fields to be calculated from the length of headers and the length of the link-layer frame.

The generation requires one octet and the CID may require up to 2 octets. There are length fields of 2 octets in the IPv6 Base Header, the IPv4 header, and the UDP header.

A full TCP header will thus have at least 2 octets available in the IP header to pass the 8 bit CID, which is sufficient. There will be more than two octets available if there is more than one IP header.

[RFC-1144] uses the 8 bit Protocol field of the IPv4 header to pass the CID. We cannot use the corresponding method as the sequence of IPv6 extension headers is not fixed and CID values are not disjoint from the legal values of Next Header fields.

An IPv6/UDP or IPv4/UDP packet will have 4 octets available to pass the generation and the CID, so all CID sizes may be used. Fragmented or encrypted packet streams may have only 2 octets available to pass the generation and CID. Thus, 8-bit CIDs may be the only CID sizes that can be used for such packet streams. When IPv6/IPv4 or IPv4/IPv6 tunneling is used, there will be at least 4 octets available, and both CID sizes may be used.

The generation value is passed in the higher order octet of the first length field in the full header. When only one length field is available, the 8-bit CID is passed in the low order octet. When two length fields are available, the lowest two octets of the CID are passed in the second length field and the low order octet of the first length field carries the highest octet of the CID.

5.3.1. Use of length fields in full TCP headers

Use of first length field:

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Length field   | LSB of pkt nr |      CID      |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Use of second length field if available:

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Second length field  | MSB of pkt nr |       0       |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pkt nr is short for packet sequence number, described in section 11.2.

5.3.2. Use of length fields in full non-TCP headers

Full non-TCP headers with 8-bit CID:

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              First length field   |0|D| Generation|      CID      |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Second length field (if avail.) | 0 | Data (if D=1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Full non-TCP headers with 16-bit CID:

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              First length field   |1|D| Generation| Data (if D=1) |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Second length field  |              CID              |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first bit in the first length field indicates the length of the CID. The Data field is zero if D is zero. The use of the D bit and Data field is explained in section 12.