Cell Relay Archive

[Dan <dan@logicdevices.com>]

I came across a conversation between three guys dicussing STM headers
and CRC.
Here are some highlights..
enjoy Dan


Raj described the CRC-8 used for the ATM HEC(Header Error Correction) as
a Hamming
code with
all of the odd-weight code words removed. An error pattern with two bits
will
always be detected, since the resulting pattern is always distance 2
from
any other code word.

Paul said he's seen CRCs used in several places (not just ATM HEC)
supposedly for single bit error correction.  It's never looked like
a good idea to him tho.  If the block being protected is more
than a few bytes long, the probability of miscorrection
becomes uncomfortably high he goes on to say. And in his oppion in the
case of ATM, you just do not get any useful benefit out of doing header
error
correction.

James responds that SDL also uses CRC that way, but only once it's
already in sync.
In SDL while detecting synchronization, the error correction feature
is disabled, and the CRC must match exactly.  Once synchronized, any
of 33 distinct CRC residues are accepted; 32 representing bit errors
in one location of the header, and 1 representing intact headers.
CRCs form a Galios field.  In general, as long as the messages are of
fixed length (4 octets for ATM and 2 for SDL, not including the CRC
length) and are short enough compared to the distance between errors
that miscorrections are unlikely. James didn't agree with Paul on the
statement
that CRC's in header was a bad idea because single bit error correction
when you're
in a known synchronized state is useful on media (such as fiber) that
tend to
occasionally garble individual bits (but not runs of bits) and where the
cost of
resynchronizing is very high.  However James does say that he would
never attempt
to do this with user data.

Bert didn't have much to say, other than that he agreed with Paul.