Subject: FW: [rohc] CRC calculation example in ROHC implementer's guide

From: Remi Pelland <[email-masked]>
Date: Wed, 30 Jul 2003 09:20:01 -0400

Does anyone have any comments on my understanding of the CRC calculation -
please see below?  I haven't heard anything back from Carsten yet, and I
really do need this information quite soon.

Thanks in advance,
Rémi.

-----Original Message-----
From: Remi Pelland [mailto:[email-masked]]
Sent: Thursday, July 24, 2003 6:23 PM
To: 'Carsten Bormann'; [email-masked]
Subject: [rohc] CRC calculation example in ROHC implementer's guide

Carsten,

I am not very familiar with CRC calculations and I have a question about the
algorithm you provided in the ROHC implementer's guide.  Actually, I want to
make sure I get it straight :

a) Assume the data on which the CRC is to be calculated is located somewhere
in memory;
b) The CRC calculation starts with the LSB of the first byte and bits are
processed sequentially until the MSB of the first byte is reached and
processed;
c) Then, it processes the LSB of the second byte and progresses until it
reaches the MSB of the second byte;
d) Bits are processed from LSB to MSB until the last byte is reached and
processed.  The last bit processed is thus the MSB of the last byte.

Do I have the proper understanding?

I have not seen anything in RFC-3095 saying that for each byte, the LSB is
the first bit that is shifted in the calculation register.  Instead, I was
under the impression that the data over which the CRC is calculated would
simply be treated as a stream of bits in memory, starting with the MSB of
the first byte and progressing linearly until the LSB of the last byte.

Was this method chosen so bits are processed in the order they are sent out
on the network? (Assuming all link layers send the LSB first.)

Thanks,
Rémi.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Alan Kennington <[email-masked]>
Date: Thu, 31 Jul 2003 00:37:44 +0930

> really do need this information quite soon.

Re'mi,

I'm not an expert on CRC coding, but I'll say how I see the story here.

The CRC-8 in ROHC (RFC 3095) is identical to the CRC8 in ATM cells,
where 8 bits protect 32 bits in the 5 octet header.
(In fact, I believe this actually gives you at least 1 bit of error
correction, not just detection.)

The CRC-32 in ROHC is identical to the CRC-32 in AAL-5.

I know about these because I coded them in simulation software for
AAL and ATM in the olden days.

Now the Telcos always number bits from left to right, and CCITT
(in the olden days) used to do this, whereas computer people number
the bits from the right. So there has always been confusion because of this.
(I once worked in a company where the software people wrote all of the
software with the bits backwards relative to the hardware people, and
they only discovered this after they worked separately for 12 months!)

Since the Telco sector thinks that bit 0 is on the left, that means that
the ROHC CRC polynomials follow the Telco thinking rather computer science.

The order in which bits are fed onto the line is not knowable from 
layers 4, 3 and 2 in which we are working. Some links might even send
the bits in parallel, or interleaved etc. Therefore chronological order
of bits cannot logically be referred to when defining CRC calculations.

I checked Carsten Bormann's algorithms relative to my old ATM and AAL5
software, and the CRC values are correct according to those definitions.

A consequence of this is that the C or Perl algorithms look a bit strange.

About the total ordering of bits, the order of bits must be as if
they were transmitted LSBit first, but the bytes all look backwards
to a computer scientist:

8 9 10 11 12 13 14 15    0 1 2 3 4 5 6 7     <== power of 2
       octet 0               octet 1

So the processing shifts the computer scientist's LSBit into the
register first, and progresses through the octets from first to last.

So I agree with your steps a to d, but this is because of the 
Telco/PTT bit-ordering, not because of the physical layer temporal order.

Cheers,
Alan.

PS.  As the Germans always say:  Alles ohne Gewa"hr!

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+0930 http://www.topology.org/site/timezone.html
 pgp-key: http://www.topology.org/ak/key_ak2.asc
    note: My e-mail address often changes due to spam abuse.
        : If your e-mail bounces, please visit topology.org/extra/email.php