tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5225

 
 
 

RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite

Part 4 of 4, p. 100 to 124
Prev RFC Part

 


prevText      Top      Up      ToC       Page 100 
6.9.  Feedback Formats and Options

6.9.1.  Feedback Formats

   This section describes the feedback format for ROHCv2 profiles, using
   the formats described in Section 5.2.3 of [RFC4995].

   The Acknowledgment Number field of the feedback formats contains the
   least significant bits of the MSN (see Section 6.3.1) that
   corresponds to the reference header that is being acknowledged.  A
   reference header is a header that has been successfully CRC-8
   validated or CRC verified.  If there is no reference header
   available, the feedback MUST carry an ACKNUMBER-NOT-VALID option.
   FEEDBACK-1

Top      Up      ToC       Page 101 
        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |     Acknowledgment Number     |
      +---+---+---+---+---+---+---+---+

      Acknowledgment Number: The eight least significant bits of the
      MSN.

   A FEEDBACK-1 is an ACK.  In order to send a NACK or a STATIC-NACK,
   FEEDBACK-2 must be used.

   FEEDBACK-2

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |Acktype| Acknowledgment Number |
      +---+---+---+---+---+---+---+---+
      |     Acknowledgment Number     |
      +---+---+---+---+---+---+---+---+
      |              CRC              |
      +---+---+---+---+---+---+---+---+
      /       Feedback options        /
      +---+---+---+---+---+---+---+---+

      Acktype:

         0 = ACK

         1 = NACK

         2 = STATIC-NACK

         3 is reserved (MUST NOT be used for parsability)

      Acknowledgment Number: The least significant bits of the MSN.

      CRC: 8-bit CRC computed over the entire feedback payload including
      any CID fields but excluding the feedback type, the 'Size' field,
      and the 'Code' octet, using the polynomial defined in Section
      5.3.1.1 of [RFC4995].  If the CID is given with an Add-CID octet,
      the Add-CID octet immediately precedes the FEEDBACK-1 or
      FEEDBACK-2 format.  For purposes of computing the CRC, the CRC
      field is zero.

      Feedback options: A variable number of feedback options, see
      Section 6.9.2.  Options may appear in any order.

Top      Up      ToC       Page 102 
   A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an
   acknowledgment for a successfully decompressed packet, which
   corresponds to a packet whose LSBs match the Acknowledgment Number of
   the feedback element, unless the ACKNUMBER-NOT-VALID option (see
   Section 6.9.2.2) appears in the feedback element.

   The FEEDBACK-2 format always carries a CRC and is thus more robust
   than the FEEDBACK-1 format.  When receiving FEEDBACK-2, the
   compressor MUST verify the information by computing the CRC and
   comparing the result with the CRC carried in the feedback format.  If
   the two are not identical, the feedback element MUST be discarded.

6.9.2.  Feedback Options

   A feedback option has variable length and the following general
   format:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |   Opt Type    |    Opt Len    |
      +---+---+---+---+---+---+---+---+
      /          Option Data          /  Opt Len (octets)
      +---+---+---+---+---+---+---+---+

      Opt Type: Unsigned integer that represents the type of the
      feedback option.  Section 6.9.2.1 through Section 6.9.2.4
      describes the ROHCv2 feedback options.

      Opt Len: Unsigned integer that represents the length of the Option
      Data field, in octets.

      Option Data: Feedback type specific data.  Present if the value of
      the Opt Len field is set to a non-zero value.

6.9.2.1.  The REJECT Option

   The REJECT option informs the compressor that the decompressor does
   not have sufficient resources to handle the flow.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |  Opt Type = 2 |  Opt Len = 0  |
      +---+---+---+---+---+---+---+---+

   When receiving a REJECT option, the compressor MUST stop compressing
   the packet flow, and SHOULD refrain from attempting to increase the
   number of compressed packet flows for some time.  The REJECT option

Top      Up      ToC       Page 103 
   MUST NOT appear more than once in the FEEDBACK-2 format; otherwise,
   the compressor MUST discard the entire feedback element.

6.9.2.2.  The ACKNUMBER-NOT-VALID Option

   The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment
   Number field of the feedback is not valid.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |  Opt Type = 3 |  Opt Len = 0  |
      +---+---+---+---+---+---+---+---+

   A compressor MUST NOT use the Acknowledgment Number of the feedback
   to find the corresponding sent header when this option is present.
   When this option is used, the Acknowledgment Number field of the
   FEEDBACK-2 format is set to zero.  Consequently, a NACK or a STATIC-
   NACK feedback type sent with the ACKNUMBER-NOT-VALID option is
   equivalent to a STATIC-NACK with respect to the type of context
   repair requested by the decompressor.

   The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the
   FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
   feedback element.

6.9.2.3.  The CONTEXT_MEMORY Option

   The CONTEXT_MEMORY option informs the compressor that the
   decompressor does not have sufficient memory resources to handle the
   context of the packet flow, as the flow is currently compressed.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |  Opt Type = 9 |  Opt Len = 0  |
      +---+---+---+---+---+---+---+---+

   When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
   actions to compress the packet flow in a way that requires less
   decompressor memory resources or stop compressing the packet flow.
   The CONTEXT_MEMORY option MUST NOT appear more than once in the
   FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
   feedback element.

6.9.2.4.  The CLOCK_RESOLUTION Option

   The CLOCK_RESOLUTION option informs the compressor of the clock
   resolution of the decompressor.  It also informs whether or not the
   decompressor supports timer-based compression of the RTP TS timestamp

Top      Up      ToC       Page 104 
   (see Section 6.6.9).  The CLOCK_RESOLUTION option is applicable per
   channel, i.e., it applies to any context associated with a profile
   for which the option is relevant between a compressor and
   decompressor pair.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | Opt Type = 10 |  Opt Len = 1  |
      +---+---+---+---+---+---+---+---+
      |     Clock resolution (ms)     |
      +---+---+---+---+---+---+---+---+

      Clock resolution: Unsigned integer that represents the clock
      resolution of the decompressor expressed in milliseconds.

   The smallest clock resolution that can be indicated is 1 millisecond.
   The value zero has a special meaning: it indicates that the
   decompressor cannot do timer-based compression of the RTP Timestamp.
   The CLOCK_RESOLUTION option MUST NOT appear more than once in the
   FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
   feedback element.

6.9.2.5.  Unknown Option Types

   If an option type other than those defined in this document is
   encountered, the compressor MUST discard the entire feedback element.

7.  Security Considerations

   Impairments such as bit errors on the received compressed headers,
   missing packets, and reordering between packets could cause the
   header decompressor to reconstitute erroneous packets, i.e., packets
   that do not match the original packet, but still have a valid IP, UDP
   (or UDP-Lite), and RTP headers, and possibly also valid UDP (or UDP-
   Lite) checksums.

   The header compression profiles defined herein use an internal
   checksum for verification of reconstructed headers.  This reduces the
   probability that a header decompressor delivers erroneous packets to
   upper layers without the error being noticed.  In particular, the
   probability that consecutive erroneous packets are not detected by
   the internal checksum is close to zero.

   This small but non-zero probability remains unchanged when integrity
   protection is applied after compression and verified before
   decompression, in the case where an attacker could discard or reorder
   packets between the compression endpoints.

Top      Up      ToC       Page 105 
   The impairments mentioned above could be caused by a malfunctioning
   or malicious header compressor.  Such corruption may be detected with
   end-to-end integrity mechanisms that will not be affected by the
   compression.  Moreover, the internal checksum can also be useful in
   the case of malfunctioning compressors.

   Denial-of-service attacks are possible if an intruder can introduce
   (for example) bogus IR or FEEDBACK packets onto the link and thereby
   cause compression efficiency to be reduced.  However, an intruder
   having the ability to inject arbitrary packets at the link layer in
   this manner raises additional security issues that dwarf those
   related to the use of header compression.

8.  IANA Considerations

   The following ROHC profile identifiers have been assigned by the IANA
   for the profiles defined in this document:

     Identifier        Profile
     ----------        -------
     0x0101            ROHCv2 RTP
     0x0102            ROHCv2 UDP
     0x0103            ROHCv2 ESP
     0x0104            ROHCv2 IP
     0x0107            ROHCv2 RTP/UDP-Lite
     0x0108            ROHCv2 UDP-Lite

9.  Acknowledgements

   The authors would like to thank Mark West, Robert Finking, Haipeng
   Jin, and Rohit Kapoor for serving as committed document reviewers,
   and also for constructive discussions during the development of this
   document.  Thanks to Carl Knutsson for his extensive contribution to
   this specification, as well as to Jani Juvan and Anders Edqvist for
   useful comments and feedback.  Thanks also to Elwyn Davies for his
   review as the General Area Review Team (Gen-ART) reviewer, and to
   Stephen Kent for his review on behalf of the IETF security
   directorate, during IETF last-call.  Finally, thanks to the many
   people who have contributed to previous ROHC specifications and
   supported this effort.

Top      Up      ToC       Page 106 
10.  References

10.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
              October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC4019]  Pelletier, G., "RObust Header Compression (ROHC): Profiles
              for User Datagram Protocol (UDP) Lite", RFC 4019,
              April 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4995]  Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
              Header Compression (ROHC) Framework", RFC 4995, July 2007.

Top      Up      ToC       Page 107 
   [RFC4997]  Finking, R. and G. Pelletier, "Formal Notation for RObust
              Header Compression (ROHC-FN)", RFC 4997, July 2007.

10.2.  Informative References

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

   [RFC3843]  Jonsson, L-E. and G. Pelletier, "RObust Header Compression
              (ROHC): A Compression Profile for IP", RFC 3843,
              June 2004.

   [RFC4224]  Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
              Header Compression (ROHC): ROHC over Channels That Can
              Reorder Packets", RFC 4224, January 2006.

Top      Up      ToC       Page 108 
Appendix A.  Detailed Classification of Header Fields

   Header compression is possible due 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 fields in the headers compressible by these
   profiles are classified and analyzed.  The analysis is based on
   behavior for the types of traffic that are expected to be the most
   frequently compressed (e.g., RTP field behavior is based on voice
   and/or video traffic behavior).

   Fields are classified as belonging to one of the following 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 included in compressed packets.

   STATIC - These fields are expected to be constant throughout the
   lifetime of the flow; in general, it is sufficient to design a
   compressed format so that these fields are only updated by IR
   packets.

   STATIC-DEF - These fields are expected to be constant throughout the
   lifetime of the flow and their values can be used to define a flow.
   They are only sent in IR packets.

   STATIC-KNOWN - These fields are expected to have well-known values
   and therefore do not need to be communicated at all.

   SEMISTATIC - These fields are unchanged most of the time.  However,
   occasionally the value changes but will revert to its original value.
   For ROHCv2, the values of such fields do not need to be possible to
   change with the smallest compressed packet formats, but should be
   possible to change via slightly larger compressed packets.

   RARELY CHANGING (RACH) - These are fields that change their values
   occasionally and then keep their new values.  For ROHCv2, the values
   of such fields do not need to be possible to change with the smallest
   compressed packet formats, but should be possible to change via
   slightly larger compressed packets.

   IRREGULAR - These are the fields for which no useful change pattern
   can be identified and should be transmitted uncompressed in all
   compressed packets.

Top      Up      ToC       Page 109 
   PATTERN - These are fields that change between each packet, but
   change in a predictable pattern.

A.1.  IPv4 Header Fields

   +------------------------+----------------+
   | Field                  | Class          |
   +------------------------+----------------+
   | Version                | STATIC-KNOWN   |
   | Header Length          | STATIC-KNOWN   |
   | Type Of Service        | RACH           |
   | Packet Length          | INFERRED       |
   | Identification         |                |
   |             Sequential | PATTERN        |
   |             Seq. swap  | PATTERN        |
   |             Random     | IRREGULAR      |
   |             Zero       | STATIC         |
   | Reserved flag          | STATIC-KNOWN   |
   | Don't Fragment flag    | RACH           |
   | More Fragments flag    | STATIC-KNOWN   |
   | Fragment Offset        | STATIC-KNOWN   |
   | Time To Live           | RACH           |
   | Protocol               | STATIC-DEF     |
   | Header Checksum        | INFERRED       |
   | Source Address         | STATIC-DEF     |
   | Destination Address    | STATIC-DEF     |
   +------------------------+----------------+

   Version

      The version field states which IP version is used and is set to
      the value four.

   Header Length

      As long as no options are present in the IP header, the header
      length is constant with the value five.  If there are options, the
      field could be RACH or STATIC-DEF, but only option-less headers
      are compressed by ROHCv2 profiles.  The field is therefore
      classified as STATIC-KNOWN.

   Type Of Service

      For the type of flows compressed by the ROHCv2 profiles, the DSCP
      (Differentiated Services Code Point) and ECN (Explicit Congestion
      Notification) fields are expected to change relatively seldom.

Top      Up      ToC       Page 110 
   Packet Length

      Information about packet length is expected to be provided by the
      link layer.  The field is therefore classified as INFERRED.

   IPv4 Identification

      The Identification field (IP-ID) is used to identify what
      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, but the expected behaviors
      have been separated into four classes.

      Sequential

         In this behavior, the IP-ID is expected to increment by one for
         most packets, but may increment by a value larger than one,
         depending on the behavior of the transmitting IPv4 stack.

      Sequential Swapped

         When using this behavior, the IP-ID behaves as in the
         Sequential behavior, but the two bytes of IP-ID are byte-
         swapped.  Therefore, the IP-ID can be swapped before
         compression to make it behave exactly as the Sequential
         behavior.

      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, and 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.

      Zero

         This behavior, although not a legal implementation of IPv4, is
         sometimes seen in existing IPv4 stacks.  When this behavior is
         used, all IP packets have the IP-ID value set to zero.

Top      Up      ToC       Page 111 
   Flags

      The Reserved flag must be set to zero and is therefore classified
      as STATIC-KNOWN.  The Don't Fragment (DF) flag changes rarely and
      is therefore classified as RACH.  Finally, the More Fragments (MF)
      flag is expected to be zero because IP fragments will not be
      compressed by ROHC and is therefore classified as STATIC-KNOWN.

   Fragment Offset

      Under the assumption that no fragmentation occurs, the fragment
      offset is always zero and is therefore classified as STATIC-KNOWN.

   Time To Live

      The Time To Live field is expected to be constant during the
      lifetime of a flow or to alternate between a limited number of
      values due to route changes.

   Protocol

      This field will have the same value in all packets of a flow and
      is therefore classified as STATIC-DEF.

   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 flow and must thus be
      constant for all packets in the flow.

Top      Up      ToC       Page 112 
A.2.  IPv6 Header Fields

   +----------------------+----------------+
   | Field                | Class          |
   +----------------------+----------------+
   | Version              | STATIC-KNOWN   |
   | Traffic Class        | RACH           |
   | Flow Label           | STATIC-DEF     |
   | Payload Length       | INFERRED       |
   | Next Header          | STATIC-DEF     |
   | Hop Limit            | RACH           |
   | Source Address       | STATIC-DEF     |
   | Destination Address  | STATIC-DEF     |
   +----------------------+----------------+

   Version

      The version field states which IP version is used and is set to
      the value six.

   Traffic Class

      For the type of flows compressed by the ROHCv2 profiles, the DSCP
      and ECN fields are expected to change relatively seldom.

   Flow Label

      This field may be used to identify packets belonging to a specific
      flow.  If it is not used, the value should be set to zero.
      Otherwise, all packets belonging to the same flow must have the
      same value in this field.  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 have the same value in all packets of a flow and
      is therefore classified as STATIC-DEF.

Top      Up      ToC       Page 113 
   Hop Limit

      The Hop Limit field is expected to be constant during the lifetime
      of a flow or to alternate between a limited number of values due
      to route changes.

   Source and Destination addresses

      These fields are part of the definition of a flow and must thus be
      constant for all packets in the flow.  The fields are therefore
      classified as STATIC-DEF.

A.3.  UDP Header Fields

   +------------------+-------------+
   | Field            | Class       |
   +------------------+-------------+
   | Source Port      | STATIC-DEF  |
   | Destination Port | STATIC-DEF  |
   | Length           | INFERRED    |
   | Checksum         |             |
   |         Disabled | STATIC      |
   |         Enabled  | IRREGULAR   |
   +------------------+-------------+

   Source and Destination ports

      These fields are part of the definition of a flow and must thus be
      constant for all packets in the flow.

   Length

      Information about packet length is expected to be provided by the
      link layer.  The field is therefore classified as INFERRED.

   Checksum

      The checksum can be optional.  If disabled, its value is
      constantly zero and can 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      Up      ToC       Page 114 
A.4.  UDP-Lite Header Fields

   +--------------------+-------------+
   | Field              | Class       |
   +--------------------+-------------+
   | Source Port        | STATIC-DEF  |
   | Destination Port   | STATIC-DEF  |
   | Checksum Coverage  |             |
   |        Zero        | STATIC-DEF  |
   |        Constant    | INFERRED    |
   |        Variable    | IRREGULAR   |
   | Checksum           | IRREGULAR   |
   +--------------------+-------------+

   Source and Destination Port

      These fields are part of the definition of a flow and must thus be
      constant for all packets in the flow.

   Checksum Coverage

      The Checksum Coverage field may behave in different ways: it may
      have a value of zero, it may be equal to the datagram length, or
      it may have any value between eight octets and the length of the
      datagram.  From a compression perspective, this field is expected
      to either be entirely predictable (for the cases where it follows
      the same behavior as the UDP Length field or where it takes on a
      constant value) or to change randomly for each packet (making the
      value unpredictable from a header-compression perspective).  For
      all cases, the behavior itself is not expected to change for this
      field during the lifetime of a packet flow, or to change
      relatively seldom.

   Checksum

      The information used for the calculation of the UDP-Lite checksum
      is governed by the value of the checksum coverage and minimally
      includes the UDP-Lite header.  The checksum is a changing field
      that must always be sent as-is.

Top      Up      ToC       Page 115 
A.5.  RTP Header Fields

   +----------------+----------------+
   | Field          | Class          |
   +----------------+----------------+
   | Version        | STATIC-KNOWN   |
   | Padding        | RACH           |
   | Extension      | RACH           |
   | CSRC Counter   | RACH           |
   | Marker         | SEMISTATIC     |
   | Payload Type   | RACH           |
   | Sequence Number| PATTERN        |
   | Timestamp      | PATTERN        |
   | SSRC           | STATIC-DEF     |
   | CSRC           | RACH           |
   +----------------+----------------+

   Version

      This field is expected to have the value two and 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 most or all
      packets.  The field is classified as RACH to allow for the case
      where the value of this field changes.

   Extension

      If RTP extensions are used by the application, these extensions
      are often present in all packets, although the use of extensions
      is infrequent.  To allow efficient compression of a flow using
      extensions in only a few packets, this field is classified as
      RACH.

   CSRC Count

      This field indicates the number of CSRC items present in the CSRC
      list.  This number is expected to be mostly constant on a packet-
      to-packet basis and when it changes, change by small amounts.  As
      long as no RTP mixer is used, the value of this field will be
      zero.

Top      Up      ToC       Page 116 
   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.

   Payload Type

      Applications could adapt to congestion by changing payload type
      and/or frame sizes, but that is not expected to happen frequently,
      so this field is classified as RACH.

   RTP Sequence Number

      The RTP Sequence Number will be incremented by one for each packet
      sent.

   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 value, which
         corresponds 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 for certain
         coding schemes.  The change in timestamp value, expressed as a
         multiple of the picture clock frequency, is in most cases
         within a limited range.

   SSRC

      This field is part of the definition of a flow and must thus be
      constant for all packets in the flow.  The field is therefore
      classified as STATIC-DEF.

Top      Up      ToC       Page 117 
   Contributing Sources (CSRC)

      The participants in a session, who are identified by the CSRC
      fields, are usually expected to be unchanged on a packet-to-packet
      basis, but will infrequently change by a few additions and/or
      removals.

A.6.  ESP Header Fields

   +------------------+-------------+
   | Field            | Class       |
   +------------------+-------------+
   | SPI              | STATIC-DEF  |
   | Sequence Number  | PATTERN     |
   +------------------+-------------+

   SPI

      This field is used to identify a distinct flow between two IPsec
      peers and it changes rarely; therefore, it is classified as
      STATIC-DEF.

   ESP Sequence Number

      The ESP Sequence Number will be incremented by one for each packet
      sent.

A.7.  IPv6 Extension Header Fields

   +-----------------------+---------------+
   | Field                 | Class         |
   +-----------------------+---------------+
   | Next Header           | STATIC-DEF    |
   | Ext Hdr Len           |               |
   |      Routing          | STATIC-DEF    |
   |      Hop-by-hop       | STATIC        |
   |      Destination      | STATIC        |
   | Options               |               |
   |      Routing          | STATIC-DEF    |
   |      Hop-by-hop       | RACH          |
   |      Destination      | RACH          |
   +-----------------------+---------------+

   Next Header

      This field will have the same value in all packets of a flow and
      is therefore classified as STATIC-DEF.

Top      Up      ToC       Page 118 
   Ext Hdr Len

      For the Routing header, it is expected that the length will remain
      constant for the duration of the flow, and that a change in the
      length should be classified as a new flow by the ROHC compressor.
      For Hop-by-hop and Destination options headers, the length is
      expected to remain static, but can be updated by an IR packet.

   Options

      For the Routing header, it is expected that the option content
      will remain constant for the duration of the flow, and that a
      change in the routing information should be classified as a new
      flow by the ROHC compressor.  For Hop-by-hop and Destination
      options headers, the options are expected to remain static, but
      can be updated by an IR packet.

A.8.  GRE Header Fields

   +--------------------+---------------+
   | Field              | Class         |
   +--------------------+---------------+
   | C flag             | STATIC        |
   | K flag             | STATIC        |
   | S flag             | STATIC        |
   | R flag             | STATIC-KNOWN  |
   | Reserved0, Version | STATIC-KNOWN  |
   | Protocol           | STATIC-DEF    |
   | Checksum           | IRREGULAR     |
   | Reserved           | STATIC-KNOWN  |
   | Sequence Number    | PATTERN       |
   | Key                | STATIC-DEF    |
   +--------------------+---------------+

   Flags

      The four flag bits are not expected to change for the duration of
      the flow, and the R flag is expected to always be set to zero.

   Reserved0, Version

      Both of these fields are expected to be set to zero for the
      duration of any flow.

   Protocol

      This field will have the same value in all packets of a flow and
      is therefore classified as STATIC-DEF.

Top      Up      ToC       Page 119 
   Checksum

      When the checksum field is present, it is expected to behave
      unpredictably.

   Reserved

      When present, this field is expected to be set to zero.

   Sequence Number

      When present, the Sequence Number increases by one for each
      packet.

   Key

      When present, the Key field is used to define the flow and does
      not change.

A.9.  MINE Header Fields

   +---------------------+----------------+
   | Field               | Class          |
   +---------------------+----------------+
   | Protocol            | STATIC-DEF     |
   | S bit               | STATIC-DEF     |
   | Reserved            | STATIC-KNOWN   |
   | Checksum            | INFERRED       |
   | Source Address      | STATIC-DEF     |
   | Destination Address | STATIC-DEF     |
   +---------------------+----------------+

   Protocol

      This field will have the same value in all packets of a flow and
      is therefore classified as STATIC-DEF.

   S bit

      The S bit is not expected to change during a flow.

   Reserved

      The reserved field is expected to be set to zero.

Top      Up      ToC       Page 120 
   Checksum

      The header checksum protects individual routing hops from
      processing a corrupted header.  Since all fields of this header
      are compressed away, there is no need to include this checksum in
      compressed packets and it can be regenerated at the decompressor
      side.

   Source and Destination Addresses

      These fields can be used to define the flow and are not expected
      to change.

A.10.  AH Header Fields

   +---------------------+----------------+
   | Field               | Class          |
   +---------------------+----------------+
   | Next Header         | STATIC-DEF     |
   | Payload Length      | STATIC         |
   | Reserved            | STATIC-KNOWN   |
   | SPI                 | STATIC-DEF     |
   | Sequence Number     | PATTERN        |
   | ICV                 | IRREGULAR      |
   +---------------------+----------------+

   Next Header

      This field will have the same value in all packets of a flow and
      is therefore classified as STATIC-DEF.

   Payload Length

      It is expected that the length of the header is constant for the
      duration of the flow.

   Reserved

      The value of this field will be set to zero.

   SPI

      This field is used to identify a specific flow and only changes
      when the sequence number wraps around, and is therefore classified
      as STATIC-DEF.

Top      Up      ToC       Page 121 
   Sequence Number

      The Sequence Number will be incremented by one for each packet
      sent.

   ICV

      The ICV is expected to behave unpredictably and is therefore
      classified as IRREGULAR.

Appendix B.  Compressor Implementation Guidelines

   This section describes some guiding principles for implementing a
   ROHCv2 compressor with focus on how to efficiently select appropriate
   packet formats.  The text in this appendix should be considered
   guidelines; it does not define any normative requirement on how
   ROHCv2 profiles are implemented.

B.1.  Reference Management

   The compressor usually maintains a sliding window of reference
   headers, which contains as many references as needed for the
   optimistic approach.  Each reference contains a description of which
   changes occurred in the flow between two consecutive headers in the
   flow, and a new reference is inserted into the window each time a
   packet is compressed by this context.  A reference may for example be
   implemented as a stored copy of the uncompressed header being
   represented.  When the compressor is confident that a specific
   reference is no longer used by the decompressor (for example by using
   the optimistic approach or feedback received), the reference is
   removed from the sliding window.

B.2.  Window-based LSB Encoding (W-LSB)

   Section 5.1.1 describes how the optimistic approach impacts the
   packet format selection for the compressor.  Exactly how the
   compressor selects a packet format is up to the implementation to
   decide, but the following is an example of how this process can be
   performed for lsb-encoded fields through the use of Window-based LSB
   encoding (W-LSB).

   With W-LSB encoding, the compressor uses a number of references (a
   window) from its context.  What references to use is determined by
   its optimistic approach.  The compressor extracts the value of the
   field to be W-LSB encoded from each reference in the window, and
   finds the maximum and minimum values.  Once it determines these
   values, the compressor uses the assumption that the decompressor has
   a value for this field within the range given by these boundaries

Top      Up      ToC       Page 122 
   (inclusively) as its reference.  The compressor can then select a
   number of LSBs from the value to be compressed, so that the LSBs can
   be decompressed regardless of whether the decompressor uses the
   minimum value, the maximum value or any other value in the range of
   possible references.

B.3.  W-LSB Encoding and Timer-based Compression

   Section 6.6.9 defines decompressor behavior for timer-based RTP
   timestamp compression.  This section gives guidelines on how the
   compressor should determine the number of LSB bits it should send for
   the timestamp field.  When using timer-based compression, this number
   depends on the sum of the jitter before the compressor and the jitter
   between the compressor and decompressor.

   The jitter before the compressor can be estimated using the following
   computation:

       Max_Jitter_BC =
            max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|,
               for all headers j in the sliding window}

   where (T_n - T_j) is the difference in the timestamp between the
   currently compressed header and a reference header and (a_n - a_j) is
   the difference in arrival time between those same two headers.

   In addition to this, the compressor needs to estimate an upper bound
   for the jitter between the compressor and decompressor
   (Max_Jitter_CD).  This information may for example come from lower
   layers.

   A compressor implementation can determine whether the difference in
   clock resolution between the compressor and decompressor induces an
   error when performing integer arithmetics; it can then treat this
   error as additional jitter.

   After obtaining estimates for the jitters, the number of bits needed
   to transmit is obtained using the following calculation:

       ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1))

   This number is then used to select a packet format that contains at
   least this many scaled timestamp bits.

Top      Up      ToC       Page 123 
Authors' Addresses

   Ghyslain Pelletier
   Ericsson
   Box 920
   Lulea  SE-971 28
   Sweden

   Phone: +46 (0) 8 404 29 43
   EMail: ghyslain.pelletier@ericsson.com


   Kristofer Sandlund
   Ericsson
   Box 920
   Lulea  SE-971 28
   Sweden

   Phone: +46 (0) 8 404 41 58
   EMail: kristofer.sandlund@ericsson.com

Top      Up      ToC       Page 124 
Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.