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 2 of 4, p. 19 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
6.  ROHCv2 Profiles (Normative)

6.1.  Channel Parameters, Segmentation, and Reordering

   The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of
   [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU)
   MUST be set to 0, if the configuration of the ROHC channel contains
   at least one ROHCv2 profile in the list of supported profiles (i.e.,
   the PROFILES parameter) and if the channel cannot guarantee in-order
   delivery of packets between compression endpoints.

Top      Up      ToC       Page 20 
6.2.  Profile Operation, Per-context

   ROHCv2 profiles operate differently, per context, depending on how
   the decompressor makes use of the feedback channel, if any.  Once the
   decompressor uses the feedback channel for a context, it establishes
   the feedback channel for that CID.

   The compressor always starts with the assumption that the
   decompressor will not send feedback when it initializes a new context
   (see also the definition of a new context in Section 5.1.1. of
   [RFC4995], i.e., there is no established feedback channel for the new
   context.  At this point, despite the use of the optimistic approach,
   decompression failure is still possible because the decompressor may
   not have received sufficient information to correctly decompress the
   packets; therefore, until the decompressor has established a feedback
   channel, the compressor SHOULD periodically send IR packets.  The
   periodicity can be based on timeouts, on the number of compressed
   packets sent for the flow, or any other strategy the implementer
   chooses.

   The reception of either positive feedback (ACKs) or negative feedback
   (NACKs or STATIC-NACKs) from the decompressor establishes the
   feedback channel for the context (CID) for which the feedback was
   received.  Once there is an established feedback channel for a
   specific context, the compressor can make use of this feedback to
   estimate the current state of the decompressor.  This helps to
   increase the compression efficiency by providing the information
   needed for the compressor to achieve the necessary confidence level.
   When the feedback channel is established, it becomes superfluous for
   the compressor to send periodic refreshes, and instead it can rely
   entirely on the optimistic approach and feedback from the
   decompressor.

   The decompressor MAY send positive feedback (ACKs) to initially
   establish the feedback channel for a particular flow.  Either
   positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs)
   establishes this channel.  Once it has established a feedback channel
   for a CID, the decompressor is REQUIRED to continue sending feedback
   for the lifetime of the context (i.e., until it receives an IR packet
   that associates the CID to a different profile), to send error
   recovery requests and (optionally) acknowledgments of significant
   context updates.

   Compression without an established feedback channel will be less
   efficient, because of the periodic refreshes and the lack of feedback
   to trigger error recovery; there will also be a slightly higher
   probability of loss propagation compared to the case where the
   decompressor uses feedback.

Top      Up      ToC       Page 21 
6.3.  Control Fields

   ROHCv2 defines a number of control fields that are used by the
   decompressor in its interpretation of the header formats received
   from the compressor.  The control fields listed in the following
   subsections are defined using the formal notation [RFC4997] in
   Section 6.8.2.4 of this document.

6.3.1.  Master Sequence Number (MSN)

   The Master Sequence Number (MSN) field is either taken from a field
   that already exists in one of the headers of the protocol that the
   profile compresses (e.g., RTP SN), or alternatively it is created at
   the compressor.  There is one MSN space per context.

   The MSN field has the following two functions:

   o  Differentiating between reference headers when receiving feedback
      data;

   o  Inferring the value of incrementing fields (e.g., IPv4
      Identifier).

   There is one MSN field in every ROHCv2 header, i.e., the MSN is
   always present in each header type sent by the compressor.  The MSN
   is sent in full in IR headers, while it can be lsb encoded within CO
   header formats.  The decompressor always includes LSBs of the MSN in
   the Acknowledgment Number field in feedback (see Section 6.9).  The
   compressor can later use this field to infer what packet the
   decompressor is acknowledging.

   For profiles for which the MSN is created by the compressor (i.e.,
   0x0102, 0x0104, and 0x0108), the following applies:

   o  The compressor only initializes the MSN for a context when that
      context is first created or when the profile associated with a
      context changes;

   o  When the MSN is initialized, it is initialized to a random value;

   o  The value of the MSN SHOULD be incremented by one for each packet
      that the compressor sends for a specific CID.

6.3.2.  Reordering Ratio

   The control field reorder_ratio specifies how much reordering is
   handled by the lsb encoding of the MSN.  This is useful when header
   compression is performed over links with varying reordering

Top      Up      ToC       Page 22 
   characteristics.  The reorder_ratio control field provides the means
   for the compressor to adjust the robustness characteristics of the
   lsb encoding method with respect to reordering and consecutive
   losses, as described in Section 5.1.2.

6.3.3.  IP-ID Behavior

   The IP-ID field of the IPv4 header can have different change
   patterns: sequential in network byte order, sequential byte-swapped,
   random or constant (a constant value of zero, although not conformant
   with [RFC0791], has been observed in practice).  There is one IP-ID
   behavior control field per IP header.  The control field for the
   IP-ID behavior of the innermost IP header determines which set of
   header formats is used.  The IP-ID behavior control field is also
   used to determine the contents of the irregular chain item, for each
   IP header.

   ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
   order or byte-swapped) to any IP-ID but the one in the innermost IP
   header when compressing more than one level of IP headers.  This is
   because only the IP-ID of the innermost IP header is likely to have a
   sufficiently close correlation with the MSN to compress it as a
   sequentially changing field.  Therefore, a compressor MUST assign
   either the constant zero IP-ID or the random IP-ID behavior to
   tunneling headers.

6.3.4.  UDP-Lite Coverage Behavior

   The control field coverage_behavior specifies how the checksum
   coverage field of the UDP-Lite header is compressed with RoHCv2.  It
   can indicate one of the following encoding methods: irregular,
   static, or inferred encoding.

6.3.5.  Timestamp Stride

   The ts_stride control field is used in scaled RTP timestamp encoding
   (see Section 6.6.8).  It defines the expected increase in the RTP
   timestamp between consecutive RTP sequence numbers.

6.3.6.  Time Stride

   The time_stride control field is used in timer-based compression
   encoding (see Section 6.6.9).  When timer-based compression is used,
   time_stride should be set to the expected difference in arrival time
   between consecutive RTP packets.

Top      Up      ToC       Page 23 
6.3.7.  CRC-3 for Control Fields

   ROHCv2 profiles define a CRC-3 calculated over a number of control
   fields.  This 3-bit CRC protecting the control fields is present in
   the header format for the co_common and co_repair header types.

   The decompressor MUST always validate the integrity of the control
   fields covered by this 3-bit CRC when processing a co_common or a
   co_repair compressed header.

   Failure to validate the control fields using this CRC should be
   considered as a decompression failure by the decompressor in the
   algorithm that assesses the validity of the context.  However, if the
   decompression attempt can be verified using either the CRC-3 or the
   CRC-7 calculated over the uncompressed header, the decompressor MAY
   still forward the decompressed header to upper layers.  This is
   because the protected control fields are not always used to
   decompress the header (i.e., co_common or co_repair) that updates
   their respective value.

   The CRC polynomial and coverage of this CRC-3 is defined in
   Section 6.6.11.

6.4.  Reconstruction and Verification

   Validation of the IR header (8-bit CRC)

      The decompressor MUST always validate the integrity of the IR
      header using the 8-bit CRC carried within the IR header.  When the
      header is validated, the decompressor updates the context with the
      information in the IR header.  Otherwise, if the IR cannot be
      validated, the context MUST NOT be updated and the IR header MUST
      NOT be delivered to upper layers.

   Verification of CO headers (3-bit CRC or 7-bit CRC)

      The decompressor MUST always verify the decompression of a CO
      header using the CRC carried within the compressed header.  When
      the decompression is verified and successful, the decompressor
      updates the context with the information received in the CO
      header; otherwise, if the reconstructed header fails the CRC
      verification, these updates MUST NOT be performed.

      A packet for which the decompression attempt cannot be verified
      using the CRC MUST NOT be delivered to upper layers.

Top      Up      ToC       Page 24 
      Decompressor implementations may attempt corrective or repair
      measures on CO headers prior to performing the above actions, and
      the result of any decompression attempt MUST be verified using the
      CRC.

6.5.  Compressed Header Chains

   Some header types use one or more chains containing sub-header
   information.  The function of a chain is to group fields based on
   similar characteristics, such as static, dynamic, or irregular
   fields.

   Chaining is done by appending an item for each header to the chain in
   their order of appearance in the uncompressed packet, starting from
   the fields in the outermost header.

   In the text below, the term <protocol_name> is used to identify
   formal notation names corresponding to different protocol headers.
   The mapping between these is defined in the following table:

     +----------------------------------+---------------+
     | Protocol                         | protocol_name |
     +----------------------------------+---------------+
     | IPv4                    RFC 0791 | ipv4          |
     | IPv6                    RFC 2460 | ipv6          |
     | UDP                     RFC 0768 | udp           |
     | RTP                     RFC 3550 | rtp           |
     | ESP                     RFC 4303 | esp           |
     | UDP-Lite                RFC 3828 | udp_lite      |
     | AH                      RFC 4302 | ah            |
     | GRE           RFC 2784, RFC 2890 | gre           |
     | MINE                    RFC 2004 | mine          |
     | IPv6 Destination Option RFC 2460 | dest_opt      |
     | IPv6 Hop-by-hop Options RFC 2460 | hop_opt       |
     | IPv6 Routing Header     RFC 2460 | rout_opt      |
     +----------------------------------+---------------+

   Static chain:

      The static chain consists of one item for each header of the chain
      of protocol headers that is compressed, starting from the
      outermost IP header.  In the formal description of the header
      formats, this static chain item for each header type is labeled
      <protocol_name>_static.  The static chain is only used in the IR
      header format.

Top      Up      ToC       Page 25 
   Dynamic chain:

      The dynamic chain consists of one item for each header of the
      chain of protocol headers that is compressed, starting from the
      outermost IP header.  In the formal description of the header
      formats, the dynamic chain item for each header type is labeled
      <protocol_name>_dynamic.  The dynamic chain is only used in the IR
      and co_repair header formats.

   Irregular chain:

      The structure of the irregular chain is analogous to the structure
      of the static chain.  For each compressed header that uses the
      general format of Section 6.8, the irregular chain is appended at
      a specific location in the general format of the compressed
      headers.  In the formal description of the header formats, the
      irregular chain item for each header type is a format whose name
      is suffixed by "_irregular".  The irregular chain is used in all
      CO headers, except for the co_repair format.

      The format of the irregular chain for the innermost IP header
      differs from the format used for the outer IP headers, because the
      innermost IP header is part of the compressed base header.  In the
      definition of the header formats using the formal notation, the
      argument "is_innermost", which is passed to the corresponding
      encoding method (ipv4 or ipv6), determines what irregular chain
      items to use.  The format of the irregular chain item for the
      outer IP headers is also determined using one flag for TTL/Hop
      Limit and TOS/TC.  This flag is defined in the format of some of
      the compressed base headers.

   ROHCv2 profiles compress extension headers as other headers, and thus
   extension headers have a static chain, a dynamic chain, and an
   irregular chain.

   ROHCv2 profiles define chains for all headers that can be compressed,
   i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP-Lite
   [RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE
   [RFC2784][RFC2890], MINE [RFC2004], IPv6 Destination Options header
   [RFC2460], IPv6 Hop-by-hop Options header [RFC2460], and IPv6 Routing
   header [RFC2460].

6.6.  Header Formats and Encoding Methods

   The header formats are defined using the ROHC formal notation.  Some
   of the encoding methods used in the header formats are defined in
   [RFC4997], while other methods are defined in this section.

Top      Up      ToC       Page 26 
6.6.1.  baseheader_extension_headers

   The baseheader_extension_headers encoding method skips over all
   fields of the extension headers of the innermost IP header, without
   encoding any of them.  Fields in these extension headers are instead
   encoded in the irregular chain.

   This encoding is used in CO headers (see Section 6.8.2).  The
   innermost IP header is combined with other header(s) (i.e., UDP, UDP-
   Lite, RTP) to create the compressed base header.  In this case, there
   may be a number of extension headers between the IP headers and the
   other headers.

   The base header defines a representation of the extension headers, to
   comply with the syntax of the formal notation; this encoding method
   provides this representation.

6.6.2.  baseheader_outer_headers

   The baseheader_outer_headers encoding method skips over all the
   fields of the extension header(s) that do not belong to the innermost
   IP header, without encoding any of them.  Changing fields in outer
   headers are instead handled by the irregular chain.

   This encoding method, similarly to the baseheader_extension_headers
   encoding method above, is necessary to keep the definition of the
   header formats syntactically correct.  It describes tunneling IP
   headers and their respective extension headers (i.e., all headers
   located before the innermost IP header) for CO headers (see
   Section 6.8.2).

6.6.3.  inferred_udp_length

   The decompressor infers the value of the UDP length field as being
   the sum of the UDP header length and the UDP payload length.  The
   compressor must therefore ensure that the UDP length field is
   consistent with the length field(s) of preceding subheaders, i.e.,
   there must not be any padding after the UDP payload that is covered
   by the IP Length.

   This encoding method is also used for the UDP-Lite Checksum Coverage
   field when it behaves in the same manner as the UDP length field
   (i.e., when the checksum always covers the entire UDP-Lite payload).

6.6.4.  inferred_ip_v4_header_checksum

   This encoding method compresses the header checksum field of the IPv4
   header.  This checksum is defined in RFC 791 [RFC0791] as follows:

Top      Up      ToC       Page 27 
      Header Checksum: 16 bits

         A checksum on the header only.  Since some header fields change
         (e.g., time to live), this is recomputed and verified at each
         point that the internet header is processed.

      The checksum algorithm is:

         The checksum field is the 16 bit one's complement of the one's
         complement sum of all 16 bit words in the header.  For purposes
         of computing the checksum, the value of the checksum field is
         zero.

   As described above, the header checksum protects individual hops from
   processing a corrupted header.  As the data that this checksum
   protects is mostly compressed away and is instead taken from state
   stored in the context, this checksum becomes cumulative to the ROHC
   CRC.  When using this encoding method, the checksum is recomputed by
   the decompressor.

   The inferred_ip_v4_header_checksum encoding method thus compresses
   the header checksum field of the IPv4 header down to a size of zero
   bits, i.e., no bits are transmitted in compressed headers for this
   field.  Using this encoding method, the decompressor infers the value
   of this field using the computation above.

   The compressor MAY use the header checksum to validate the
   correctness of the header before compressing it, to avoid processing
   a corrupted header.

6.6.5.  inferred_mine_header_checksum

   This encoding method compresses the minimal encapsulation header
   checksum.  This checksum is defined in RFC 2004 [RFC2004] as follows:

      Header Checksum

         The 16-bit one's complement of the one's complement sum of all
         16-bit words in the minimal forwarding header.  For purposes of
         computing the checksum, the value of the checksum field is 0.
         The IP header and IP payload (after the minimal forwarding
         header) are not included in this checksum computation.

   The inferred_mine_header_checksum encoding method compresses the
   minimal encapsulation header checksum down to a size of zero bits,
   i.e., no bits are transmitted in compressed headers for this field.
   Using this encoding method, the decompressor infers the value of this
   field using the above computation.

Top      Up      ToC       Page 28 
   The motivations for inferring this checksum are similar to the ones
   explained above in Section 6.6.4.

   The compressor MAY use the minimal encapsulation header checksum to
   validate the correctness of the header before compressing it, to
   avoid processing a corrupted header.

6.6.6.  inferred_ip_v4_length

   This encoding method compresses the total length field of the IPv4
   header.  The total length field of the IPv4 header is defined in RFC
   791 [RFC0791] as follows:

      Total Length: 16 bits

         Total Length is the length of the datagram, measured in octets,
         including internet header and data.  This field allows the
         length of a datagram to be up to 65,535 octets.

   The inferred_ip_v4_length encoding method compresses the IPv4 header
   checksum down to a size of zero bits, i.e., no bits are transmitted
   in compressed headers for this field.  Using this encoding method,
   the decompressor infers the value of this field by counting in octets
   the length of the entire packet after decompression.

6.6.7.  inferred_ip_v6_length

   This encoding method compresses the payload length field in the IPv6
   header.  This length field is defined in RFC 2460 [RFC2460] as
   follows:

      Payload Length: 16-bit unsigned integer

         Length of the IPv6 payload, i.e., the rest of the packet
         following this IPv6 header, in octets.  (Note that any
         extension headers present are considered part of the payload,
         i.e., included in the length count.)

   The "inferred_ip_v6_length" encoding method compresses the payload
   length field of the IPv6 header down to a size of zero bits, i.e., no
   bits are transmitted in compressed headers for this field.  Using
   this encoding method, the decompressor infers the value of this field
   by counting in octets the length of the entire packet after
   decompression.

   IPv6 headers using the jumbo payload option of RFC 2675 [RFC2675]
   will not be compressible with this encoding method since the value of
   the payload length field does not match the length of the packet.

Top      Up      ToC       Page 29 
6.6.8.  Scaled RTP Timestamp Compression

   This section provides additional details on encodings used to scale
   the RTP timestamp, as defined in the formal notation in
   Section 6.8.2.4.

   The RTP timestamp (TS) usually increases by a multiple of the RTP
   Sequence Number's (SN's) increase and is therefore a suitable
   candidate for scaled encoding.  This scaling factor is labeled
   ts_stride in the definition of the profile in the formal notation.
   The compressor sets the scaling factor based on the change in TS with
   respect to the change in the RTP SN.

   The default value of the scaling factor ts_stride is 160, as defined
   in Section 6.8.2.4.  To use a different value for ts_stride, the
   compressor explicitly updates the value of ts_stride to the
   decompressor using one of the header formats that can carry this
   information.

   When the compressor uses a scaling factor that is different than the
   default value of ts_stride, it can only use the new scaling factor
   once it has enough confidence that the decompressor has successfully
   calculated the residue (ts_offset) of the scaling function for the
   timestamp.  The compressor achieves this by sending unscaled
   timestamp values, to allow the decompressor to establish the residue
   based on the current ts_stride.  The compressor MAY send the unscaled
   timestamp in the same compressed header(s) used to establish the
   value of ts_stride.

   Once the compressor has gained enough confidence that both the value
   of the scaling factor and the value of the residue have been
   established in the decompressor, the compressor can start compressing
   packets using the new scaling factor.

   When the compressor detects that the residue (ts_offset) value has
   changed, it MUST NOT select a compressed header format that uses the
   scaled timestamp encoding before it has re-established the residue as
   described above.

   When the value of the timestamp field wraps around, the value of the
   residue of the scaling function is likely to change.  When this
   occurs, the compressor re-establishes the new residue value as
   described above.

   If the decompressor receives a compressed header containing scaled
   timestamp bits while the ts_stride equals zero, it MUST NOT deliver
   the packet to upper layers and it SHOULD treat this as a CRC
   verification failure.

Top      Up      ToC       Page 30 
   Whether or not the scaling is applied to the RTP TS field is up to
   the compressor implementation (i.e., the use of scaling is OPTIONAL),
   and is indicated by the tsc_indicator control field.  In case scaling
   is applied to the RTP TS field, the value of ts_stride used by the
   compressor is up to the implementation.  A value of ts_stride that is
   set to the expected increase in the RTP timestamp between consecutive
   unit increases of the RTP SN will provide the most gain for the
   scaled encoding.  Other values may provide the same gain in some
   situations, but may reduce the gain in others.

   When scaled timestamp encoding is used for header formats that do not
   transmit any lsb-encoded timestamp bits at all, the
   inferred_scaled_field encoding of Section 6.6.10 is used for encoding
   the timestamp.

6.6.9.  timer_based_lsb

   The timer-based compression encoding method, timer_based_lsb,
   compresses a field whose change pattern approximates a linear
   function of the time of day.

   This encoding uses the local clock to obtain an approximation of the
   value that it encodes.  The approximated value is then used as a
   reference value together with the num_lsbs_param least-significant
   bits received as the encoded value, where num_lsbs_param represents a
   number of bits that is sufficient to uniquely represent the encoded
   value in the presence of jitter between compression endpoints.

     ts_scaled =:= timer_based_lsb(<time_stride_param>,
                                   <num_lsbs_param>, <offset_param>)

   The parameters "num_lsbs_param" and "offset_param" are the parameters
   to use for the lsb encoding, i.e., the number of least significant
   bits and the interpretation interval offset, respectively.  The
   parameter "time_stride_param" represents the context value of the
   control field time_stride.

   This encoding method always uses a scaled version of the field it
   compresses.

   The value of the field is decoded by calculating an approximation of
   the scaled value, using:

        tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride.

Top      Up      ToC       Page 31 
      where:

      - tsc_ref is a reference value of the scaled representation
        of the field.
      - a_n is the arrival time associated with the value to decode.
      - a_ref is the arrival time associated with the reference header.
      - tsc_ref_advanced is an approximation of the scaled value
        of the field.

   The lsb encoding is then applied using the num_lsbs_param bits
   received in the compressed header and the tsc_ref_advanced as
   "ref_value" (as per Section 4.11.5 of [RFC4997]).

   Appendix B.3 provides an example of how the compressor can calculate
   jitter.

   The control field time_stride controls whether or not the
   timer_based_lsb method is used in the CO header.  The decompressor
   SHOULD send the CLOCK_RESOLUTION option with a zero value, if:

   o  it receives a non-zero time_stride value, and

   o  it has not previously sent a CLOCK_RESOLUTION feedback with a non-
      zero value.

   This is to allow compression to recover from the case where a
   compressor erroneously activates timer-based compression.

   The support and usage of timer-based compression is OPTIONAL for both
   the compressor and the decompressor; the compressor is not required
   to set the time_stride control field to a non-zero value when it has
   received a non-zero value for the CLOCK_RESOLUTION option.

6.6.10.  inferred_scaled_field

   The inferred_scaled_field encoding method encodes a field that is
   defined as changing in relation to the MSN, and for which the
   increase with respect to the MSN can be scaled by some scaling
   factor.  This encoding method is used in compressed header formats
   that do not contain any bits for the scaled field.  In this case, the
   decompressor infers the unscaled value of the scaled field from the
   MSN field.  The unscaled value is calculated according to the
   following formula:

      unscaled_value = delta_msn * stride + reference_unscaled_value

   where "delta_msn" is the difference in MSN between the reference
   value of the MSN in the context and the value of the MSN decompressed

Top      Up      ToC       Page 32 
   from this packet, "reference_unscaled_value" is the value of the
   field being scaled in the context, and "stride" is the scaling value
   for this field.

   For example, when this encoding method is applied to the RTP
   timestamp in the RTP profile, the calculation above becomes:

      timestamp = delta_msn * ts_stride + reference_timestamp

6.6.11.  control_crc3_encoding

   The control_crc3_encoding method provides a CRC calculated over a
   number of control fields.  The definition of this encoding method is
   the same as for the "crc" encoding method specified in Section 4.11.6
   of [RFC4997], with the difference being that the data covered by the
   CRC is given by a concatenated list of control fields.

   In other words, the definition of the control_crc3_encoding method is
   equivalent to the following definition:

     control_crc_encoding(ctrl_data_value, ctrl_data_length)
     {
       UNCOMPRESSED {
       }

       COMPRESSED {
         control_crc3 =:=
           crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
       }
     }

   where the parameter "ctrl_data_value" binds to the concatenated
   values of the following control fields, in the order listed below:

   o  reorder_ratio, 2 bits padded with 6 MSB of zeroes

   o  ts_stride, 32 bits (only for profiles 0x0101 and 0x0107)

   o  time_stride, 32 bits (only for profiles 0x0101 and 0x0107)

   o  msn, 16 bits (not applicable for profiles 0x0101, 0x0103, and
      0x0107)

   o  coverage_behavior, 2 bits padded with 6 MSB of zeroes (only for
      profiles 0x0107 and 0x0108)

Top      Up      ToC       Page 33 
   o  ip_id_behavior, one octet for each IP header in the compressible
      header chain starting from the outermost header.  Each octet
      consists of 2 bits padded with 6 MSBs of zeroes.

   The "ctrl_data_length" binds to the sum of the length of the control
   field(s) that are applicable to the specific profile.

   The decompressor uses the resulting 3-bit CRC to validate the control
   fields that are updated by the co_common and co_repair header
   formats; this CRC cannot be used to verify the outcome of a
   decompression attempt.

   This CRC protects the update of control fields, as the updated values
   are not always used to decompress the header that carries them and
   thus are not protected by the CRC-7 verification.  This prevents
   impairments that could occur if the decompression of a co_common or
   of a co_repair succeeds and the decompressor sends positive feedback,
   while for some reason the control fields are incorrectly updated.

6.6.12.  inferred_sequential_ip_id

   This encoding method is used with a sequential IP-ID behavior
   (sequential or sequential byte-swapped) and when there are no coded
   IP-ID bits in the compressed header.  In this case, the IP-ID offset
   from the MSN is constant, and the IP-ID increases by the same amount
   as the MSN (similar to the inferred_scaled_field encoding method).

   The decompressor calculates the value for the IP-ID according to the
   following formula:

      IP-ID = delta_msn + reference_IP_ID_value

   where "delta_msn" is the difference between the reference value of
   the MSN in the context and the uncompressed value of the MSN
   associated to the compressed header, and where
   "reference_IP_ID_value" is the value of the IP-ID in the context.
   For swapped IP-ID behavior (i.e., when ip_id_behavior_innermost is
   set to IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED), "reference_IP_ID_value"
   and "IP-ID" are byte-swapped with regard to the corresponding fields
   in the context.

   If the IP-ID behavior is random or zero, this encoding method does
   not update any fields.

Top      Up      ToC       Page 34 
6.6.13.  list_csrc(cc_value)

   This encoding method compresses the list of RTP CSRC identifiers
   using list compression.  This encoding establishes a content for the
   different CSRC identifiers (items) and a list describing the order in
   which they appear.

   The compressor passes an argument (cc_value) to this encoding method:
   this is the value of the CC field taken from the RTP header.  The
   decompressor is required to bind the value of this argument to the
   number of items in the list, which will allow the decompressor to
   correctly reconstruct the CC field.

6.6.13.1.  List Compression

   The CSRC identifiers in the uncompressed packet can be represented as
   an ordered list, whose order and presence are usually constant
   between packets.  The generic structure of such a list is as follows:

            +--------+--------+--...--+--------+
      list: | item 1 | item 2 |       | item n |
            +--------+--------+--...--+--------+

   When performing list compression on a CSRC list, each item is the
   uncompressed value of one CSRC identifier.

   The basic principles of list-based compression are the following:

   When initializing the context:

   1) The complete representation of the list of CSRC identifiers is
      transmitted.

   Then, once the context has been initialized:

   2) When the list is unchanged, a compressed header that does not
      contain information about the list can be used.

   3) When the list changes, a compressed list is sent in the compressed
      header, including a representation of its structure and order.
      Previously unknown items are sent uncompressed in the list, while
      previously known items are only represented by an index pointing
      to the item stored in the context.

Top      Up      ToC       Page 35 
6.6.13.2.  Table-based Item Compression

   The table-based item compression compresses individual items sent in
   compressed lists.  The compressor assigns a unique identifier,
   "Index", to each item "Item" of a list.

   Compressor Logic

      The compressor conceptually maintains an item table containing all
      items, indexed using "Index".  The (Index, Item) pair is sent
      together in compressed lists until the compressor gains enough
      confidence that the decompressor has observed the mapping between
      items and their respective index.  Confidence is obtained from the
      reception of an acknowledgment from the decompressor, or by
      sending (Index, Item) pairs using the optimistic approach.  Once
      confidence is obtained, the index alone is sent in compressed
      lists to indicate the presence of the item corresponding to this
      index.

      The compressor MAY reset its item table upon receiving a negative
      acknowledgement.

      The compressor MAY reassign an existing index to a new item by re-
      establishing the mapping using the procedure described above.

   Decompressor Logic

      The decompressor conceptually maintains an item table that
      contains all (Index, Item) pairs received.  The item table is
      updated whenever an (Index, Item) pair is received and
      decompression is successful (CRC verification, or CRC-8
      validation).  The decompressor retrieves the item from the table
      whenever an Index is received without an accompanying Item.

      If an index is received without an accompanying Item and the
      decompressor does not have any context for this index, the
      decompressor MUST NOT deliver the packet to upper layers.

6.6.13.3.  Encoding of Compressed Lists

   Each item present in a compressed list is represented by:

   o  an Index into the table of items, and a presence bit indicating if
      a compressed representation of the item is present in the list.

   o  an item (if the presence bit is set).

Top      Up      ToC       Page 36 
   If the presence bit is not set, the item must already be known by the
   decompressor.

   A compressed list of items uses the following encoding:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | Reserved  |PS |       m       |
      +---+---+---+---+---+---+---+---+
      |        XI_1, ..., XI_m        | m octets, or m * 4 bits
      /                --- --- --- ---/
      |               :    Padding    : if PS = 0 and m is odd
      +---+---+---+---+---+---+---+---+
      |                               |
      /      Item_1, ..., Item_n      / variable
      |                               |
      +---+---+---+---+---+---+---+---+

      Reserved: MUST be set to zero; otherwise, the decompressor MUST
      discard the packet.

      PS: Indicates size of XI fields:

         PS = 0 indicates 4-bit XI fields;

         PS = 1 indicates 8-bit XI fields.

      m: Number of XI item(s) in the compressed list.  Also, the value
      of the cc_value argument of the list_csrc encoding (see
      Section 6.6.13).

      XI_1, ..., XI_m: m XI items.  Each XI represents one item in the
      list of items of the uncompressed header, in the same order as
      they appear in the uncompressed header.

         The format of an XI item is as follows:

                   0   1   2   3
                 +---+---+---+---+
         PS = 0: | X |   Index   |
                 +---+---+---+---+

                   0   1   2   3   4   5   6   7
                 +---+---+---+---+---+---+---+---+
         PS = 1: | X | Reserved  |     Index     |
                 +---+---+---+---+---+---+---+---+

         X: Indicates whether the item is present in the list:

Top      Up      ToC       Page 37 
            X = 1 indicates that the item corresponding to the Index is
            sent in the Item_1, ..., Item_n list;

            X = 0 indicates that the item corresponding to the Index is
            not sent.

         Reserved: MUST be set to zero; otherwise, the decompressor MUST
         discard the packet.

         Index: An index into the item table.  See Section 6.6.13.4

         When 4-bit XI items are used, the XI items are placed in octets
         in the following manner:

           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         |     XI_k      |    XI_k + 1   |
         +---+---+---+---+---+---+---+---+

      Padding: A 4-bit Padding field is present when PS = 0 and the
      number of XIs is odd.  The Padding field MUST be set to zero;
      otherwise, the decompressor MUST discard the packet.

      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  Each entry in the Item list is the uncompressed
      representation of one CSRC identifier.

6.6.13.4.  Item Table Mappings

   The item table for list compression is limited to 16 different items,
   since the RTP header can only carry at most 15 simultaneous CSRC
   identifiers.  The effect of having more than 16 items in the item
   table will only cause a slight overhead to the compressor when items
   are swapped in/out of the item table.

6.6.13.5.  Compressed Lists in Dynamic Chain

   A compressed list that is part of the dynamic chain must have all of
   its list items present, i.e., all X-bits in the XI list MUST be set.
   All items previously established in the item table that are not
   present in the list decompressed from this packet MUST also be
   retained in the decompressor context.

Top      Up      ToC       Page 38 
6.7.  Encoding Methods with External Parameters as Arguments

   A number of encoding methods in Section 6.8.2.4 have one or more
   arguments for which the derivation of the parameter's value is
   outside the scope of the ROHC-FN [RFC4997] specification of the
   header formats.

   The following is a list of encoding methods with external parameters
   as arguments, from Section 6.8.2.4:

   o  udp(profile_value, reorder_ratio_value)

   o  udp_lite(profile_value, reorder_ratio_value,
      coverage_behavior_value)

   o  esp(profile_value, reorder_ratio_value)

   o  rtp(profile_value, ts_stride_value, time_stride_value,
      reorder_ratio_value)

   o  ipv4(profile_value, is_innermost, outer_ip_flag,
      ip_id_behavior_value, reorder_ratio_value))

   o  ipv6(profile_value, is_innermost, outer_ip_flag,
      reorder_ratio_value))

   o  iponly_baseheader(profile_value, outer_ip_flag,
      ip_id_behavior_value, reorder_ratio_value)

   o  udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
      reorder_ratio_value)

   o  udplite_baseheader(profile_value, outer_ip_flag,
      ip_id_behavior_value, reorder_ratio_value)

   o  esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
      reorder_ratio_value)

   o  rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
      outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)

   o  udplite_rtp_baseheader(profile_value, ts_stride_value,
      time_stride_value, outer_ip_flag, ip_id_behavior_value,
      reorder_ratio_value, coverage_behavior_value)

   The following applies for all parameters listed below: At the
   compressor, the value of the parameter is set according to the
   recommendations for each parameter.  At the decompressor, the value

Top      Up      ToC       Page 39 
   of the parameter is set to undefined and will get bound by encoding
   methods, except where otherwise noted.

   The following is a list of external arguments with their respective
   definition:

   o  profile_value:

         Set to the 16-bit number that identifies the profile used to
         compress this packet.  When processing the static chain at the
         decompressor, this parameter is set to the value of the profile
         field in the IR header (see Section 6.8.1).

   o  reorder_ratio_value:

         Set to a 2-bit integer value, using one of the constants whose
         name begins with the prefix REORDERING_ and as defined in
         Section 6.8.2.4.

   o  ip_id_behavior_value:

         Set to a 2-bit integer value, using one of the constants whose
         name begins with the prefix IP_ID_BEHAVIOR_ and as defined in
         Section 6.8.2.4.

   o  coverage_behavior_value:

         Set to a 2-bit integer value, using one of the constants whose
         name begins with the prefix UDP_LITE_COVERAGE_ and as defined
         in Section 6.8.2.4.

   o  outer_ip_flag:

         This parameter is set to 1 if at least one of the TOS/TC or
         TTL/Hop Limit fields in outer IP headers has changed compared
         to their reference values in the context; otherwise, it is set
         to 0.  This flag may only be set to 1 for the "co_common"
         header format in the different profiles.

   o  is_innermost:

         This boolean flag is set to 1 when processing the innermost of
         the compressible IP headers; otherwise, it is set to 0.

Top      Up      ToC       Page 40 
   o  ts_stride_value

         The value of this parameter should be set to the expected
         increase in the RTP Timestamp between consecutive RTP sequence
         numbers.  The value selected is implementation-specific.  See
         also Section 6.6.8.

   o  time_stride_value

         The value of this parameter should be set to the expected
         inter-arrival time between consecutive packets for the flow.
         The value selected is implementation-specific.  This parameter
         MUST be set to zero, unless the compressor has received a
         feedback message with the CLOCK_RESOLUTION option set to a non-
         zero value.  See also Section 6.6.9.

6.8.  Header Formats

   ROHCv2 profiles use two different header types: the Initialization
   and Refresh (IR) header type, and the Compressed header type (CO).

   The CO header type defines a number of header formats: there are two
   sets of base header formats, with a few additional formats that are
   common to both sets.

6.8.1.  Initialization and Refresh Header Format (IR)

   The IR header format uses the structure of the ROHC IR header as
   defined in Section 5.2.2.1 of [RFC4995].

   Header type: IR

      This header format communicates the static part and the dynamic
      part of the context.

Top      Up      ToC       Page 41 
   The ROHCv2 IR header has the following format:

        0   1   2   3   4   5   6   7
       --- --- --- --- --- --- --- ---
      :        Add-CID octet          : if for small CIDs and (CID != 0)
      +---+---+---+---+---+---+---+---+
      | 1   1   1   1   1   1   0   1 | IR type octet
      +---+---+---+---+---+---+---+---+
      :                               :
      /       0-2 octets of CID       / 1-2 octets if for large CIDs
      :                               :
      +---+---+---+---+---+---+---+---+
      |            Profile            | 1 octet
      +---+---+---+---+---+---+---+---+
      |              CRC              | 1 octet
      +---+---+---+---+---+---+---+---+
      |                               |
      /         Static chain          / variable length
      |                               |
       - - - - - - - - - - - - - - - -
      |                               |
      /         Dynamic chain         / variable length
      |                               |
       - - - - - - - - - - - - - - - -

      CRC: 8-bit CRC over the entire IR-header, including any CID fields
      and up until the end of the dynamic chain, using the polynomial
      defined in [RFC4995].  For purposes of computing the CRC, the CRC
      field is zero.

      Static chain: See Section 6.5.

      Dynamic chain: See Section 6.5.

6.8.2.  Compressed Header Formats (CO)

6.8.2.1.  Design Rationale for Compressed Base Headers

   The compressed header formats are defined as two separate sets for
   each profile: one set for the headers where the innermost IP header
   contains a sequential IP-ID (either network byte order or byte-
   swapped), and one set for the headers without sequential IP-ID
   (either random, zero, or no IP-ID).  There are also a number of
   common header formats shared between both sets.  In the description
   below, the naming convention used for header formats that belong to
   the sequential set is to include "seq" in the name of the format,
   while similarly "rnd" is used for those that belong to the non-
   sequential set.

Top      Up      ToC       Page 42 
   The design of the header formats is derived from the field behavior
   analysis found in Appendix A.

   All of the compressed base headers transmit lsb-encoded MSN bits and
   a CRC.

   The following header formats exist for all profiles defined in this
   document, and are common to both the sequential and the random header
   format sets:

   o  co_common: This format can be used to update the context when the
      established change pattern of a dynamic field changes, for any of
      the dynamic fields.  However, not all dynamic fields are updated
      by conveying their uncompressed value; some fields can only be
      transmitted using a compressed representation.  This format is
      especially useful when a rarely changing field needs to be
      updated.  This format contains a set of flags to indicate what
      fields are present in the header, and its size can vary
      accordingly.  This format is protected by a 7-bit CRC.  It can
      update control fields, and it thus also carries a 3-bit CRC to
      protect those fields.  This format is similar in purpose to the
      UOR-2-extension 3 format of [RFC3095].

   o  co_repair: This format can be used to update the context of all
      the dynamic fields by conveying their uncompressed value.  This is
      especially useful when context damage is assumed (e.g., from the
      reception of a NACK) and a context repair is performed.  This
      format is protected by a 7-bit CRC.  It also carries a 3-bit CRC
      over the control fields that it can update.  This format is
      similar in purpose to the IR-DYN format of [RFC3095] when
      performing context repairs.

   o  pt_0_crc3: This format conveys only the MSN; it can therefore only
      update the MSN and fields that are derived from the MSN, such as
      IP-ID and the RTP Timestamp (for applicable profiles).  It is
      protected by a 3-bit CRC.  This format is equivalent to the UO-0
      header format in [RFC3095].

   o  pt_0_crc7: This format has the same properties as pt_0_crc3, but
      is instead protected by a 7-bit CRC and contains a larger amount
      of lsb-encoded MSN bits.  This format is useful in environments
      where a high amount of reordering or a high-residual error rate
      can occur.

Top      Up      ToC       Page 43 
   The following header format descriptions apply to profiles 0x0101 and
   0x0107.

   o  pt_1_rnd: This format can convey changes to the MSN and to the RTP
      Marker bit, and it can update the RTP timestamp using scaled
      timestamp encoding.  It is protected by a 3-bit CRC.  It is
      similar in purpose to the UO-1 format in [RFC3095].

   o  pt_1_seq_id: This format can convey changes to the MSN and to the
      IP-ID.  It is protected by a 3-bit CRC.  It is similar in purpose
      to the UO-1-ID format in [RFC3095].

   o  pt_1_seq_ts: This format can convey changes to the MSN and to the
      RTP Marker bit, and it can update the RTP Timestamp using scaled
      timestamp encoding.  It is protected by a 3-bit CRC.  It is
      similar in purpose to the UO-1-TS format in [RFC3095].

   o  pt_2_rnd: This format can convey changes to the MSN, to the RTP
      Marker bit, and to the RTP Timestamp.  It is protected by a 7-bit
      CRC.  It is similar in purpose to the UOR-2 format in [RFC3095].

   o  pt_2_seq_id: This format can convey changes to the MSN and to the
      IP-ID.  It is protected by a 7-bit CRC.  It is similar in purpose
      to the UO-2-ID format in [RFC3095].

   o  pt_2_seq_ts: This format can convey changes to the MSN, to the RTP
      Marker bit and it can update the RTP Timestamp using scaled
      timestamp encoding.  It is protected by a 7-bit CRC.  It is
      similar in purpose to the UO-2-TS format in [RFC3095].

   o  pt_2_seq_both: This format can convey changes to both the RTP
      Timestamp and the IP-ID, in addition to the MSN and to the Marker
      bit.  It is protected by a 7-bit CRC.  It is similar in purpose to
      the UOR-2-ID extension 1 format in [RFC3095].

   The following header format descriptions apply to profiles 0x0102,
   0x0103, 0x0104, and 0x0108.

   o  pt_1_seq_id: This format can convey changes to the MSN and to the
      IP-ID.  It is protected by a 7-bit CRC.  It is similar in purpose
      to the UO-1-ID format in [RFC3095].

   o  pt_2_seq_id: This format can convey changes to the MSN and to the
      IP-ID.  It is protected by a 7-bit CRC.  It is similar in purpose
      to the UO-2-ID format in [RFC3095].

Top      Up      ToC       Page 44 
6.8.2.2.  co_repair Header Format

   The ROHCv2 co_repair header has the following format:

        0   1   2   3   4   5   6   7
       --- --- --- --- --- --- --- ---
      :         Add-CID octet         : if for small CIDs and CID 1-15
      +---+---+---+---+---+---+---+---+
      | 1   1   1   1   1   0   1   1 | discriminator
      +---+---+---+---+---+---+---+---+
      :                               :
      /   0, 1, or 2 octets of CID    / 1-2 octets if large CIDs
      :                               :
      +---+---+---+---+---+---+---+---+
      |r1 |         CRC-7             |
      +---+---+---+---+---+---+---+---+
      |        r2         |   CRC-3   |
      +---+---+---+---+---+---+---+---+
      |                               |
      /         Dynamic chain         / variable length
      |                               |
       - - - - - - - - - - - - - - - -

      r1: MUST be set to zero; otherwise, the decompressor MUST discard
      the packet.

      CRC-7: A 7-bit CRC over the entire uncompressed header, computed
      using the crc7 (data_value, data_length) encoding method defined
      in Section 6.8.2.4, where data_value corresponds to the entire
      uncompressed header chain and where data_length corresponds to the
      length of this header chain.

      r2: MUST be set to zero; otherwise, the decompressor MUST discard
      the packet.

      CRC-3: Encoded using the control_crc3_encoding method defined in
      Section 6.6.11.

      Dynamic chain: See Section 6.5.

6.8.2.3.  General CO Header Format

   The CO header format communicates irregularities in the packet
   header.  All CO formats carry a CRC and can update the context.  All
   CO header formats use the general format defined in this section,
   with the exception of the co_repair format, which is defined in
   Section 6.8.2.2.

Top      Up      ToC       Page 45 
   The general format for a compressed header is as follows:

        0   1   2   3   4   5   6   7
       --- --- --- --- --- --- --- ---
      :         Add-CID octet         : if for small CIDs and CID 1-15
      +---+---+---+---+---+---+---+---+
      |  first octet of base header   | (with type indication)
      +---+---+---+---+---+---+---+---+
      :                               :
      /   0, 1, or 2 octets of CID    / 1-2 octets if large CIDs
      :                               :
      +---+---+---+---+---+---+---+---+
      /   remainder of base header    / variable length
      +---+---+---+---+---+---+---+---+
      :                               :
      /        Irregular Chain        / variable length
      :                               :
       --- --- --- --- --- --- --- ---

   The base header in the figure above is the compressed representation
   of the innermost IP header and other header(s), if any, in the
   uncompressed packet.  The base header formats are defined in
   Section 6.8.2.4.  In the formal description of the header formats,
   the base header for each profile is labeled
   <profile_name>_baseheader, where <profile_name> is defined in the
   following table:

      +------------------+----------------+
      | Profile number   | profile_name   |
      +------------------+----------------+
      | 0x0101           | rtp            |
      | 0x0102           | udp            |
      | 0x0103           | esp            |
      | 0x0104           | ip             |
      | 0x0107           | udplite_rtp    |
      | 0x0108           | udplite        |
      +------------------+----------------+



(page 45 continued on part 3)

Next RFC Part