RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI

[Paul Koning <ni1d@arrl.net>]

I guess the problem with the spec is that it is a confusing mix of
pieces of the mathematical definition and pieces of description from a
specific (and unstated) implementation.

Ok, so let me propose specific replacement text.

This is for Appendix D, starting at the top of page 193 in the -09 rev
of the spec.

----------------
The generator polynomial for the CRC is x^32 + x^28 + x^27 + x^26 +
x^25 + x^23 + x^22 + x^20 + x^19 + x^18 +x^14 + x+13 + x+11 + x^10 +
x^9 + x^8 +x^6 + 1.

The CRC value for a PDU is defined mathematically as follows:

1. The first 32 bits of the PDU are complemented.

2. The N bits of the PDU are then considered to be coefficients of a
polynomial M(x) of degree N-1.  Bit 0 of byte 0, i.e., the low order
bit of the high order byte of the first word of the PDU, corresponds
to the X^(N-1) term of this polynomial, and the high order bit of the
last byte of the PDU corresponds to the x^0 term.  Note that any pad
bytes for the PDU are included.

3. M(x) is multiplied by x^32, and divided by G(x), producing a
remainder R(x) of degree < 32.

4. The coefficients of R(x) are considered to be a 32-bit sequence.

5. This bit sequence is complemented and the result is the CRC.

The CRC is trannsmitted with the high order bit (corresponding to the
x^31 term of R(x)) in the low order bit of the first byte transmitted,
and the low order bit (corresponding to the x^0 term of R(x)) in the
high order bit of the fourth byte transmitted.
----------------

This text is inspired by the text in the Ethernet spec, with some
wording changes needed for the iSCSI context.  I believe this is a
precise definition of what is needed.

For additional information, more text could be included.  For example:

----------------
The above algorithm is exactly that used in the Ethernet/802.3 LAN,
with the exception of the choice of generator polynomial.
----------------

And perhaps a note on implementation:

----------------
The above algorithm may be efficiently implemented in a variety of
ways, such as linear feedback shift registers, table lookup, etc.
----------------

Finally, we could capture the "magic constant" receive algorithm as
follows:

----------------
Implementation of the CRC32C checking for PDU reception can be done in
several ways.  

One approach is to calculate the CRC over the PDU not including the
CRC field, and compare that with the received CRC.  If the two values
are equal, the digest is considered valid.

Another approach is to perform the above algorithm over the entire
received PDU, including the CRC field.  With that approach, a valid
digest results in R(x) having the value x^28 + x^27 + x^26 + x^21 +
x^19 + x^18 +x^16 + x^12 + x^11 + x^8 + x^7 + x^6 + x^5 + x^3 + x^2 + 1,
i.e., the value of the 32-bit sequence obtained in step 4 is
0x1c2d19ed. 
----------------

Following Pat Thaler's comments, I am not proposing any more text on
implementation approaches.  Both the table based approaches and the
LFSR approach can be covered by references to literature, though
admittedly some of the references may not be all that easy to
acquire. 

So my proposal is to replace the text on page 193 up to the
"Proprietary algorithms MAY also..." with the four pieces given
above.  If people don't like the later pieces, then I'll fall back to
proposing just the first chunk of text (the formal definition of the
CRC) as replacement for the current text.

	 paul