Re: [rohc] CRC correction algorithms in ROHCv2

[Klaus Warnke <[e-mail]>]

Hi Anil,
> Is CRC Correction algorithms are used in ROHCv2?
It is not forbidden, but it is not required.
"may attempt corrective or repair measures"

But remember:
Maybe the CRC value is damaged, not the header...

I think, you can not reapir the packet, but you can reapir the
context. If you assume, a previous packet was damaged, but the CRC
check did not catched the error due to its limited length. Then the
context is damaged, but the current packet and CRC is correct. Then
you can roll back the last context updated and try again with the
current packet. This makes sense, if you receive three subsequent
packets with an CRC error. In such case, a context damaged can be
assumed. 

And remember from 4995, 5.3.1.2.  3-bit CRC in Compressed Headers:

> Therefore, compressed headers carrying a 3-bit CRC are normally not
> suitable to perform context repairs at the decompressor;

You can develop a CRC repair mechanism, if you want.  It is only
important, that the CRC verification succeeds after reapir.

> If yes, where did they mentioned the procedures?
No, but maybe you use the repair mechanism from 3095?
"5.3.2.2.5.  Repair of incorrect SN updates"

br
Klaus

At Mon, 21 Dec 2009 14:54:15 +0530,
Anil Maguluri wrote:
> Hi All,
> 
> Please clarify whether my understanding is right or not.  As per my
> understanding, there is no need of CRC Correction algorithms in
> ROHCv2 because every packet has CRC in ROHCv2. As you know the CRC
> Correction algorithms are clearly mentioned in ROHCv1 (RFC 3095).
> 
> But, the RFC 5225 has the below information:
> "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.
> 
> 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."
> 
> Please clarify the below queries.
> Is CRC Correction algorithms are used in ROHCv2?
> If yes, where did they mentioned the procedures?
> 
> Thanks for your support.
> 
> Regards,
> Anil Kumar Maguluri