CRC-3 and CRC-7 calculation in ROHCv2
"Lu, Xiaomin" <[email protected]> Mon, 24 Jan 2011 10:49:25 -0700
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <[email protected]> |
--===============0874031143==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_"
--_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 =3D:=3D 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) =3D x^0 + x^1 + x^3
crc_field =3D:=3D 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 seq=
uentially
Cover the original IP/UDP/RTP headers, instead of partitioning them into c=
rc-static and crc-dynamic
Part first?
Can anyone confirm or clarify that?
Thanks very much for your assistance!
Best Regards,
Xiaomin Lu
--_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
#800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Arial, sans-serif" size=3D"2">
<div>Hi,</div>
<div> </div>
<div>I have a question regarding the CRC-3 and CRC-7 calculations in ROHCv2=
, e.g., ROHCv2-RTP vs. ROHCv1 (RFC3095).</div>
<div> </div>
<div>In RFC3095 (Page 10), the spec says that </div>
<div> </div>
<div>"A CRC over the original header is the primary mechanism used by<=
/div>
<div> ROHC to detect incorrect decompression.=
In order to decrease</div>
<div> computational complexity, the fields of=
the header are</div>
<div> conceptually rearranged when the CRC is=
computed, so that it is</div>
<div> first computed over octets which are st=
atic (called CRC-STATIC in</div>
<div> this document) and then over octets who=
se values are expected to</div>
<div> change between packets (CRC-DYNAMIC).&n=
bsp; In this manner, the</div>
<div> intermediate result of the CRC computat=
ion, after it has covered</div>
<div> the CRC-STATIC fields, can be reused fo=
r several packets. The</div>
<div> restarted CRC computation only covers t=
he CRC-DYNAMIC octets. See</div>
<div> section 5.9."</div>
<div> </div>
<div> </div>
<div>However, in RFC4997 and RFC5225, it does not mention that concept. Ins=
tead, it says on Page 29 of </div>
<div>RFC4997:</div>
<div> </div>
<div>"That is:</div>
<div> </div>
<div> field =3D:=3D crc(<=
;num_bits>, <bit_pattern>, <initial_value>,</div>
<div> &nbs=
p; <block_da=
ta_value>, <block_data_length>);</div>
<div> </div>
<div> When specifying the bit pattern for the polynomial, each =
bit</div>
<div> represents the coefficient for the corresponding term in =
the</div>
<div> polynomial. Note that the highest order term is alw=
ays present (by</div>
<div> definition) and therefore does not need specifying in the=
bit</div>
<div> pattern. Therefore, a CRC polynomial with n terms i=
n it is</div>
<div> represented by a bit pattern with n-1 bits set.</div>
<div> </div>
<div> The CRC is calculated in least significant bit (LSB) orde=
r.</div>
<div> </div>
<div> For example:</div>
<div> </div>
<div> // 3 bit CRC, C(x) =3D x^0 + x^1 + x^=
3</div>
<div> crc_field =3D:=3D crc(3, 0x6, 0xF, THIS.CVALU=
E, THIS.CLENGTH);</div>
<div> </div>
<div> Usage of the "THIS" keyword (see Section 4.6) a=
s shown above, is</div>
<div> typical when using "crc" encoding. For ex=
ample, when used in the</div>
<div> encoding method for an entire header, it causes the CRC t=
o be</div>
<div> calculated over all fields in the header."</div>
<div> </div>
<div> </div>
<div> </div>
<div>Would that suggest the CRC-3 and CRC-7 calculation change in ROHCv2 an=
d sequentially</div>
<div>Cover the original IP/UDP/RTP headers, instead of partitioning t=
hem into crc-static and crc-dynamic</div>
<div>Part first?</div>
<div> </div>
<div>Can anyone confirm or clarify that? </div>
<div> </div>
<div>Thanks very much for your assistance!</div>
<div> </div>
<div> </div>
<div>Best Regards,</div>
<div>Xiaomin Lu</div>
<div> </div>
<div> </div>
<div> </div>
</font>
</body>
</html>
--_000_4B6A08C587958942AA3002690DD4F8C30107031B20cosmail02lsic_--
--===============0874031143==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc
--===============0874031143==--