Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5225

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

Pages: 124
Proposed Standard
Errata
Part 4 of 4 – Pages 100 to 124
First   Prev   None

Top   ToC   RFC5225 - Page 100   prevText

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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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   ToC   RFC5225 - 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.