Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3095

RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed

Pages: 168
Proposed Standard
Updated by:  37594815
Part 7 of 7 – Pages 152 to 168
First   Prev   None

Top   ToC   RFC3095 - Page 152   prevText

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.
Top   ToC   RFC3095 - Page 153

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 | +---------------------+-------------+----------------+
Top   ToC   RFC3095 - Page 154
   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       |
      +--------------+--------------+
Top   ToC   RFC3095 - Page 155

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.
Top   ToC   RFC3095 - Page 156
      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        |
      +--------------+----------------+
Top   ToC   RFC3095 - Page 157

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 | +-----------------+-------------+----------------+
Top   ToC   RFC3095 - Page 158
   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)   |
      +--------------+---------------+
Top   ToC   RFC3095 - Page 159

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.
Top   ToC   RFC3095 - Page 160
   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.
Top   ToC   RFC3095 - Page 161
   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.
Top   ToC   RFC3095 - Page 162

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.
Top   ToC   RFC3095 - Page 163
      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.
Top   ToC   RFC3095 - Page 164

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.
Top   ToC   RFC3095 - Page 165

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
Top   ToC   RFC3095 - Page 166

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
Top   ToC   RFC3095 - Page 167

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
Top   ToC   RFC3095 - Page 168
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.