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.
----------------------------------------------------------------[Page 152]
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 |
+---------------------+-------------+----------------+
----------------------------------------------------------------[Page 153]
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 |
+--------------+--------------+
----------------------------------------------------------------[Page 154]
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.
----------------------------------------------------------------[Page 155]
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 |
+--------------+----------------+
----------------------------------------------------------------[Page 156]
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 |
+-----------------+-------------+----------------+
----------------------------------------------------------------[Page 157]
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) |
+--------------+---------------+
----------------------------------------------------------------[Page 158]
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.
----------------------------------------------------------------[Page 159]
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.
----------------------------------------------------------------[Page 160]
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.
----------------------------------------------------------------[Page 161]
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.
----------------------------------------------------------------[Page 162]
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.
----------------------------------------------------------------[Page 163]
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.
----------------------------------------------------------------[Page 164]
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 Version
A.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
----------------------------------------------------------------[Page 165]
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 Timestamp
A.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
----------------------------------------------------------------[Page 166]
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
----------------------------------------------------------------[Page 167]
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.
----------------------------------------------------------------[Page 168]
Credits
-- UnKnown --
|