Subject: [rohc] CRC-3 and CRC-7 calculation in ROHCv2

From: "Lu, Xiaomin" <[email-masked]>
Date: Mon, 24 Jan 2011 10:49:25 -0700

Hi,

I have a question regarding the CRC-3 and CRC-7 calculations in ROHCv2, e.g., ROHCv2-RTP vs. ROHCv1 (RFC3095).

In RFC3095 (Page 10), the spec says that

"A CRC over the original header is the primary mechanism used by
      ROHC to detect incorrect decompression.  In order to decrease
      computational complexity, the fields of the header are
      conceptually rearranged when the CRC is computed, so that it is
      first computed over octets which are static (called CRC-STATIC in
      this document) and then over octets whose values are expected to
      change between packets (CRC-DYNAMIC).  In this manner, the
      intermediate result of the CRC computation, after it has covered
      the CRC-STATIC fields, can be reused for several packets.  The
      restarted CRC computation only covers the CRC-DYNAMIC octets.  See
      section 5.9."

However, in RFC4997 and RFC5225, it does not mention that concept. Instead, it says on Page 29 of
RFC4997:

"That is:

     field   =:=   crc(<num_bits>, <bit_pattern>, <initial_value>,
                       <block_data_value>, <block_data_length>);

   When specifying the bit pattern for the polynomial, each bit
   represents the coefficient for the corresponding term in the
   polynomial.  Note that the highest order term is always present (by
   definition) and therefore does not need specifying in the bit
   pattern.  Therefore, a CRC polynomial with n terms in it is
   represented by a bit pattern with n-1 bits set.

   The CRC is calculated in least significant bit (LSB) order.

   For example:

     // 3 bit CRC, C(x) = x^0 + x^1 + x^3
     crc_field =:= crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH);

   Usage of the "THIS" keyword (see Section 4.6) as shown above, is
   typical when using "crc" encoding.  For example, when used in the
   encoding method for an entire header, it causes the CRC to be
   calculated over all fields in the header."

Would that suggest the CRC-3 and CRC-7 calculation change in ROHCv2 and sequentially
Cover the original IP/UDP/RTP headers, instead of partitioning  them into crc-static and crc-dynamic
Part first?

Can anyone confirm or clarify that?

Thanks very much for your assistance!

Best Regards,
Xiaomin Lu

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Jan 2011 19:07:11 +0100

> Cover the original IP/UDP/RTP headers, instead of partitioning  them into crc-static and crc-dynamic

Indeed, this partitioning was an optimization that sounded clever at the time we did RFC 3095 but apparently made it harder to implement ROHC for some, so it is not used in ROHCv2.

Gruesse, Carsten