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

["CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>]

Paul,

Looks fine as long as one realizes that:

1. If someone choses to use the divide-only circuit that is commonly found
in texts they cannot initialize the registers to 1's and hope to achieve the
same effect as complementing the first 32 bits of the PDU. 

2. If someone choses to use the multiply-divide circuit as in ethernet spec
they can initialize the registers to 1's and achieve the same effect as
complementing the first 32 bits of the PDU.

I am pretty sure the intent in predecessors to the ethernet spec (FDDI,
HDLC) was to initialize the registers of the implementation to ones. The
effect, for the referenced implementation which was a multiply-divide
implementation, could be obtained by complementing the most significant bits
of the message.

Vince

|-----Original Message-----
|From: Paul Koning [mailto:ni1d@arrl.net]
|Sent: Friday, December 14, 2001 12:18 PM
|To: ltuikov@yahoo.com
|Cc: ips@ece.cmu.edu
|Subject: RE: effect of initializing CRC reg to 1's depends on
|implementati on? iSCSI
|
|
|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
|