RFC 3095
RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
Appendix A. Detailed classification of header fields
Header compression is possible thanks to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. In this appendix, all IP, UDP and RTP header fields are classified and analyzed in two steps. First, we have a general classification in A.1 where the fields are classified on the basis of stable knowledge and assumptions. The general classification does not take into account the change characteristics of changing fields because those will vary more or less depending on the implementation and on the application used. A less stable but more detailed analysis of the change characteristics is then done in A.2. Finally, A.3 summarizes this appendix with conclusions about how the various header fields should be handled by the header compression scheme to optimize compression and functionality.
A.1. General classification
At a general level, the header fields are separated into 5 classes: INFERRED These fields contain values that can be inferred from other values, for example the size of the frame carrying the packet, and thus do not have to be handled at all by the compression scheme. STATIC These fields are expected to be constant throughout the lifetime of the packet stream. Static information must in some way be communicated once. STATIC-DEF STATIC fields whose values define a packet stream. They are in general handled as STATIC. STATIC-KNOWN These STATIC fields are expected to have well-known values and therefore do not need to be communicated at all. CHANGING These fields are expected to vary in some way: randomly, within a limited value set or range, or in some other manner. In this section, each of the IP, UDP and RTP header fields is assigned to one of these classes. For all fields except those classified as CHANGING, the motives for the classification are also stated. In section A.2, CHANGING fields are further examined and classified on the basis of their expected change behavior.A.1.1. IPv6 header fields
+---------------------+-------------+----------------+ | Field | Size (bits) | Class | +---------------------+-------------+----------------+ | Version | 4 | STATIC | | Traffic Class | 8 | CHANGING | | Flow Label | 20 | STATIC-DEF | | Payload Length | 16 | INFERRED | | Next Header | 8 | STATIC | | Hop Limit | 8 | CHANGING | | Source Address | 128 | STATIC-DEF | | Destination Address | 128 | STATIC-DEF | +---------------------+-------------+----------------+
Version
The version field states which IP version is used. Packets with
different values in this field must be handled by different IP
stacks. All packets of a packet stream must therefore be of the
same IP version. Accordingly, the field is classified as STATIC.
Flow Label
This field may be used to identify packets belonging to a specific
packet stream. If not used, the value should be set to zero.
Otherwise, all packets belonging to the same stream must have the
same value in this field, it being one of the fields that define
the stream. The field is therefore classified as STATIC-DEF.
Payload Length
Information about packet length (and, consequently, payload
length) is expected to be provided by the link layer. The field
is therefore classified as INFERRED.
Next Header
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes present and sometimes
not, will the field change its value during the lifetime of the
stream. The field is therefore classified as STATIC.
Source and Destination addresses
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Total size of the fields in each class:
+--------------+--------------+
| Class | Size (octets)|
+--------------+--------------+
| INFERRED | 2 |
| STATIC | 1.5 |
| STATIC-DEF | 34.5 |
| CHANGING | 2 |
+--------------+--------------+
A.1.2. IPv4 header fields
+---------------------+-------------+----------------+ | Field | Size (bits) | Class | +---------------------+-------------+----------------+ | Version | 4 | STATIC | | Header Length | 4 | STATIC-KNOWN | | Type Of Service | 8 | CHANGING | | Packet Length | 16 | INFERRED | | Identification | 16 | CHANGING | | Reserved flag | 1 | STATIC-KNOWN | | Don't Fragment flag | 1 | STATIC | | More Fragments flag | 1 | STATIC-KNOWN | | Fragment Offset | 13 | STATIC-KNOWN | | Time To Live | 8 | CHANGING | | Protocol | 8 | STATIC | | Header Checksum | 16 | INFERRED | | Source Address | 32 | STATIC-DEF | | Destination Address | 32 | STATIC-DEF | +---------------------+-------------+----------------+ Version The version field states which IP version is used. Packets with different values in this field must be handled by different IP stacks. All packets of a packet stream must therefore be of the same IP version. Accordingly, the field is classified as STATIC. Header Length As long no options are present in the IP header, the header length is constant and well known. If there are options, the fields would be STATIC, but it is assumed here that there are no options. The field is therefore classified as STATIC-KNOWN. Packet Length Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED. Flags The Reserved flag must be set to zero and is therefore classified as STATIC-KNOWN. The Don't Fragment (DF) flag will be constant for all packets in a stream and is therefore classified as STATIC.
Finally, the More Fragments (MF) flag is expected to be zero
because fragmentation is NOT expected, due to the small packet
size expected. The More Fragments flag is therefore classified as
STATIC-KNOWN.
Fragment Offset
Under the assumption that no fragmentation occurs, the fragment
offset is always zero. The field is therefore classified as
STATIC-KNOWN.
Protocol
This field will usually have the same value in all packets of a
packet stream. It encodes the type of the subsequent header.
Only when extension headers are sometimes present and sometimes
not, will the field change its value during the lifetime of a
stream. The field is therefore classified as STATIC.
Header Checksum
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional
checksum; instead it can be regenerated at the decompressor side.
The field is therefore classified as INFERRED.
Source and Destination addresses
These fields are part of the definition of a stream and must thus
be constant for all packets in the stream. The fields are
therefore classified as STATIC-DEF.
Total size of the fields in each class:
+--------------+----------------+
| Class | Size (octets) |
+--------------+----------------+
| INFERRED | 4 |
| STATIC | 1 oct + 5 bits |
| STATIC-DEF | 8 |
| STATIC-KNOWN | 2 oct + 3 bits |
| CHANGING | 4 |
+--------------+----------------+
A.1.3. UDP header fields
+------------------+-------------+-------------+ | Field | Size (bits) | Class | +------------------+-------------+-------------+ | Source Port | 16 | STATIC-DEF | | Destination Port | 16 | STATIC-DEF | | Length | 16 | INFERRED | | Checksum | 16 | CHANGING | +------------------+-------------+-------------+ Source and Destination ports These fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF. Length This field is redundant and is therefore classified as INFERRED. Total size of the fields in each class: +------------+---------------+ | Class | Size (octets) | +------------+---------------+ | INFERRED | 2 | | STATIC-DEF | 4 | | CHANGING | 2 | +------------+---------------+A.1.4. RTP header fields
+-----------------+-------------+----------------+ | Field | Size (bits) | Class | +-----------------+-------------+----------------+ | Version | 2 | STATIC-KNOWN | | Padding | 1 | STATIC | | Extension | 1 | STATIC | | CSRC Counter | 4 | CHANGING | | Marker | 1 | CHANGING | | Payload Type | 7 | CHANGING | | Sequence Number | 16 | CHANGING | | Timestamp | 32 | CHANGING | | SSRC | 32 | STATIC-DEF | | CSRC | 0(-480) | CHANGING | +-----------------+-------------+----------------+
Version
Only one working RTP version exists, namely version 2. The field
is therefore classified as STATIC-KNOWN.
Padding
The use of this field is application-dependent, but when payload
padding is used it is likely to be present in all packets. The
field is therefore classified as STATIC.
Extension
If RTP extensions are used by the application, these extensions
are likely to be present in all packets (but the use of extensions
is very uncommon). However, for safety's sake this field is
classified as STATIC and not STATIC-KNOWN.
SSRC
This field is part of the definition of a stream and must thus be
constant for all packets in the stream. The field is therefore
classified as STATIC-DEF.
Total size of the fields in each class:
+--------------+---------------+
| Class | Size (octets) |
+--------------+---------------+
| STATIC | 2 bits |
| STATIC-DEF | 4 |
| STATIC-KNOWN | 2 bits |
| CHANGING | 7.5(-67.5) |
+--------------+---------------+
A.1.5. Summary for IP/UDP/RTP
Summarizing this for IP/UDP/RTP one obtains +----------------+----------------+----------------+ | Class \ IP ver | IPv6 (octets) | IPv4 (octets) | +----------------+----------------+----------------+ | INFERRED | 4 | 6 | | STATIC | 1 oct + 6 bits | 1 oct + 7 bits | | STATIC-DEF | 42.5 | 16 | | STATIC-KNOWN | 2 bits | 2 oct + 5 bits | | CHANGING | 11.5(-71.5) | 13.5(-73.5) | +----------------+----------------+----------------+ | Total | 60(-120) | 40(-100) | +----------------+----------------+----------------+A.2. Analysis of change patterns of header fields
To design suitable mechanisms for efficient compression of all header fields, their change patterns must be analyzed. For this reason, an extended classification is done based on the general classification in A.1, considering the fields which were labeled CHANGING in that classification. Different applications will use the fields in different ways, which may affect their behavior. For the fields whose behavior is variable, typical behavior for conversational audio and video will be discussed. The CHANGING fields are separated into five different subclasses: STATIC These are fields that were classified as CHANGING on a general basis, but are classified as STATIC here due to certain additional assumptions. SEMISTATIC These fields are STATIC most of the time. However, occasionally the value changes but reverts to its original value after a known number of packets. RARELY-CHANGING (RC) These are fields that change their values occasionally and then keep their new values. ALTERNATING These fields alternate between a small number of different values. IRREGULAR These, finally, are the fields for which no useful change pattern can be identified.
To further expand the classification possibilities without increasing complexity, the classification can be done either according to the values of the field and/or according to the values of the deltas for the field. When the classification is done, other details are also stated regarding possible additional knowledge about the field values and/or field deltas, according to the classification. For fields classified as STATIC or SEMISTATIC, the case could be that the value of the field is not only STATIC but also well KNOWN a priori (two states for SEMISTATIC fields). For fields with non-irregular change behavior, it could be known that changes usually are within a LIMITED range compared to the maximal change for the field. For other fields, the values are completely UNKNOWN.
Table A.1 classifies all the CHANGING fields on the basis of their
expected change patterns, especially for conversational audio and
video.
+------------------------+-------------+-------------+-------------+
| Field | Value/Delta | Class | Knowledge |
+========================+=============+=============+=============+
| Sequential | Delta | STATIC | KNOWN |
| -----------+-------------+-------------+-------------+
| IPv4 Id: Seq. jump | Delta | RC | LIMITED |
| -----------+-------------+-------------+-------------+
| Random | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TOS / Tr. Class | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| IP TTL / Hop Limit | Value | ALTERNATING | LIMITED |
+------------------------+-------------+-------------+-------------+
| Disabled | Value | STATIC | KNOWN |
| UDP Checksum: ---------+-------------+-------------+-------------+
| Enabled | Value | IRREGULAR | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| No mix | Value | STATIC | KNOWN |
| RTP CSRC Count: -------+-------------+-------------+-------------+
| Mixed | Value | RC | LIMITED |
+------------------------+-------------+-------------+-------------+
| RTP Marker | Value | SEMISTATIC | KNOWN/KNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Payload Type | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Sequence Number | Delta | STATIC | KNOWN |
+------------------------+-------------+-------------+-------------+
| RTP Timestamp | Delta | RC | LIMITED |
+------------------------+-------------+-------------+-------------+
| No mix | - | - | - |
| RTP CSRC List: -------+-------------+-------------+-------------+
| Mixed | Value | RC | UNKNOWN |
+------------------------+-------------+-------------+-------------+
Table A.1 : Classification of CHANGING header fields
The following subsections discuss the various header fields in
detail. Note that table A.1 and the discussions below do not
consider changes caused by loss or reordering before the compression
point.
A.2.1. IPv4 Identification
The Identification field (IP ID) of the IPv4 header is there to identify which fragments constitute a datagram when reassembling fragmented datagrams. The IPv4 specification does not specify exactly how this field is to be assigned values, only that each packet should get an IP ID that is unique for the source-destination pair and protocol for the time the datagram (or any of its fragments) could be alive in the network. This means that assignment of IP ID values can be done in various ways, which we have separated into three classes. Sequential jump This is the most common assignment policy in today's IP stacks. A single IP ID counter is used for all packet streams. When the sender is running more than one packet stream simultaneously, the IP ID can increase by more than one between packets in a stream. The IP ID values will be much more predictable and require less bits to transfer than random values, and the packet-to-packet increment (determined by the number of active outgoing packet streams and sending frequencies) will usually be limited. Random Some IP stacks assign IP ID values using a pseudo-random number generator. There is thus no correlation between the ID values of subsequent datagrams. Therefore there is no way to predict the IP ID value for the next datagram. For header compression purposes, this means that the IP ID field needs to be sent uncompressed with each datagram, resulting in two extra octets of header. IP stacks in cellular terminals SHOULD NOT use this IP ID assignment policy. Sequential This assignment policy keeps a separate counter for each outgoing packet stream and thus the IP ID value will increment by one for each packet in the stream, except at wrap around. Therefore, the delta value of the field is constant and well known a priori. When RTP is used on top of UDP and IP, the IP ID value follows the RTP Sequence Number. This assignment policy is the most desirable for header compression purposes. However, its usage is not as common as it perhaps should be. The reason may be that it can be realized only when UDP and IP are implemented together so that UDP, which separates packet streams by the Port identification fields, can make IP use separate ID counters for each packet stream.
In order to avoid violating [IPv4], packets sharing the same IP
address pair and IP protocol number cannot use the same IP ID
values. Therefore, implementations of sequential policies must
make the ID number spaces disjoint for packet streams of the same
IP protocol going between the same pair of nodes. This can be
done in a number of ways, all of which introduce occasional
jumps, and thus makes the policy less than perfectly sequential.
For header compression purposes less frequent jumps are
preferred.
It should be noted that the ID is an IPv4 mechanism and is therefore
not a problem for IPv6. For IPv4 the ID could be handled in three
different ways. First, we have the inefficient but reliable solution
where the ID field is sent as-is in all packets, increasing the
compressed headers by two octets. This is the best way to handle the
ID field if the sender uses random assignment of the ID field.
Second, there can be solutions with more flexible mechanisms
requiring less bits for the ID handling as long as sequential jump
assignment is used. Such solutions will probably require even more
bits if random assignment is used by the sender. Knowledge about the
sender's assignment policy could therefore be useful when choosing
between the two solutions above. Finally, even for IPv4, header
compression could be designed without any additional information for
the ID field included in compressed headers. To use such schemes, it
must be known which assignment policy for the ID field is being used
by the sender. That might not be possible to know, which implies
that the applicability of such solutions is very uncertain. However,
designers of IPv4 stacks for cellular terminals SHOULD use an
assignment policy close to sequential.
A.2.2. IP Traffic-Class / Type-Of-Service
The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected
to be constant during the lifetime of a packet stream or to change
relatively seldom.
A.2.3. IP Hop-Limit / Time-To-Live
The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
constant during the lifetime of a packet stream or to alternate
between a limited number of values due to route changes.
A.2.4. UDP Checksum
The UDP checksum is optional. If disabled, its value is constantly
zero and could be compressed away. If enabled, its value depends on
the payload, which for compression purposes is equivalent to it
changing randomly with every packet.
A.2.5. RTP CSRC Counter
This is a counter indicating the number of CSRC items present in the CSRC list. This number is expected to be almost constant on a packet- to-packet basis and change by small amounts. As long as no RTP mixer is used, the value of this field is zero.A.2.6. RTP Marker
For audio the marker bit should be set only in the first packet of a talkspurt, while for video it should be set in the last packet of every picture. This means that in both cases the RTP marker is classified as SEMISTATIC with well-known values for both states.A.2.7. RTP Payload Type
Changes of the RTP payload type within a packet stream are expected to be rare. Applications could adapt to congestion by changing payload type and/or frame sizes, but that is not expected to happen frequently.A.2.8. RTP Sequence Number
The RTP Sequence Number will be incremented by one for each packet sent.A.2.9. RTP Timestamp
In the audio case: As long as there are no pauses in the audio stream, the RTP Timestamp will be incremented by a constant delta, corresponding to the number of samples in the speech frame. It will thus mostly follow the RTP Sequence Number. When there has been a silent period and a new talkspurt begins, the timestamp will jump in proportion to the length of the silent period. However, the increment will probably be within a relatively limited range. In the video case: Between two consecutive packets, the timestamp will either be unchanged or increase by a multiple of a fixed value corresponding to the picture clock frequency. The timestamp can also decrease by a multiple of the fixed value if B-pictures are used. The delta interval, expressed as a multiple of the picture clock frequency, is in most cases very limited.
A.2.10. RTP Contributing Sources (CSRC)
The participants in a session, which are identified by the CSRC fields, are expected to be almost the same on a packet-to-packet basis with relatively few additions and removals. As long as RTP mixers are not used, no CSRC fields are present at all.A.3. Header compression strategies
This section elaborates on what has been done in previous sections. On the basis of the classifications, recommendations are given on how to handle the various fields in the header compression process. Seven different actions are possible; these are listed together with the fields to which each action applies.A.3.1. Do not send at all
The fields that have well known values a priori do not have to be sent at all. These are: - IPv6 Payload Length - IPv4 Header Length - IPv4 Reserved Flag - IPv4 Last Fragment Flag - IPv4 Fragment Offset - UDP Checksum (if disabled) - RTP VersionA.3.2. Transmit only initially
The fields that are constant throughout the lifetime of the packet stream have to be transmitted and correctly delivered to the decompressor only once. These are: - IP Version - IP Source Address - IP Destination Address - IPv6 Flow Label - IPv4 May Fragment Flag - UDP Source Port - UDP Destination Port - RTP Padding Flag - RTP Extension Flag - RTP SSRC
A.3.3. Transmit initially, but be prepared to update
The fields that are changing only occasionally must be transmitted initially but there must also be a way to update these fields with new values if they change. These fields are: - IPv6 Next Header - IPv6 Traffic Class - IPv6 Hop Limit - IPv4 Protocol - IPv4 Type Of Service (TOS) - IPv4 Time To Live (TTL) - RTP CSRC Counter - RTP Payload Type - RTP CSRC List Since the values of the IPv4 Protocol and the IPv6 Next Header fields are in effect linked to the type of the subsequent header, they deserve special treatment when subheaders are inserted or removed.A.3.4. Be prepared to update or send as-is frequently
For fields that normally either are constant or have values deducible from some other field, but that frequently diverge from that behavior, there must be an efficient way to update the field value or send it as-is in some packets. These fields are: - IPv4 Identification (if not sequentially assigned) - RTP Marker - RTP TimestampA.3.5. Guarantee continuous robustness
For fields that behave like a counter with a fixed delta for ALL packets, the only requirement on the transmission encoding is that packet losses between compressor and decompressor must be tolerable. If several such fields exist, all these can be communicated together. Such fields can also be used to interpret the values for fields listed in the previous section. Fields that have this counter behavior are: - IPv4 Identification (if sequentially assigned) - RTP Sequence Number
A.3.6. Transmit as-is in all packets
Fields that have completely random values for each packet must be included as-is in all compressed headers. Those fields are: - IPv4 Identification (if randomly assigned) - UDP Checksum (if enabled)A.3.7. Establish and be prepared to update delta
Finally, there is a field that is usually increasing by a fixed delta and is correlated to another field. For this field it would make sense to make that delta part of the context state. The delta must then be initiated and updated in the same way as the fields listed in A.3.3. The field to which this applies is: - RTP Timestamp
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.