RE: iSCSI v8 CRC32C

[vince_cavanna@agilent.com]

Hi Luben,

Looks like you are not taking into account the fact that iSCSi assumes that
the least significant BIT within a byte is transmitted first (whereas the
most significant BYTE is transmitted first)! Recall that the bit that is
transmitted first represents the coefficient of the highest order term of
the message polynomial. The reason for this strange behavior is the desire
to be consistent with Ethernet. It seems this detail of ethernet CRC was not
realized by many but fortunately has been captured in a parameter called
"bit reflection flag" in a popular CRC tool that many are using.

See also the attached email that I sent to the reflector in August wherein I
objected, though not strongly, to copying Ethernet to such a degree. I
subsequently yielded when it was claimed that Ethernet implementors managed
to cope with the potential source of confusion and the benefits of being
consistent outweighed the problems. Eventually we will learn to cope too
:-).

If you want a Mathematica worksheet showing the polynomial math behind the
calculations as well as the required bit/byte mappings ask me and I will dig
it up - after the Holidays. I was going to publish it to the reflector but
don't have the time to put it in a more acceptable format.

Vince


-----Original Message-----
From: Luben Tuikov [mailto:ltuikov@yahoo.com]
Sent: Tuesday, November 20, 2001 1:01 PM
To: ips@ece.cmu.edu
Subject: iSCSI v8 CRC32C


Hello,

I've been trying to get CRC32C working. I read a few papers,
derived the equations myself, etc, etc, but still cannot get
CRC32C to work...

My basic framework is: (not precomputing a table -- just force):

poly= 1edc6f41;
crc = all 1's;
while more bits in message do
	crc shift left, adding the next message bit at right;
	if carry then
		crc = crc XOR poly;
	end if;
end while;
crc = NOT crc; (e.g. complement the register)

What is wrong with this implementation?

Thanks,
-l



=====
--

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

---

• To: Julian_Satran@il.ibm.com, mbakke@cisco.com
• Subject: RE: iSCSI CRC: A CRC-checking example
• From: vince_cavanna@agilent.com
• Date: Wed, 22 Aug 2001 10:42:50 -0700
• Cc: vince_cavanna@agilent.com, Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
• Content-Type: text/plain;charset="ISO-8859-1"

Julian and Mark and others,

After I took into account the bit "reflection"  and the byte order (Big
Endian on Bytes and Little Endian on bits) I did finally obtain, using
polynomial math, the (corrected) results you show in the CRC examples. The
results have also been confirmed independently by an implementor here at
Agilent. 

I am the one who originally suggested to Julian that we specify the CRC
algorithm the same way as in ethernet even though for iSCSI it is not really
important to initialize the CRC register to all 1s and to complement the CRC
before transmission since there are other means to detect extra or missing
PDU bytes. However I had not realzied until recently that conformance with
the ethernet algorithm implies bit reflection. I had not been aware that in
ethernet the bits are sent out on the serial link with the least significant
bit first AND that the corresponding message polynomial is formed from the
bits in the sequence that they appear on the serial link; thus the need for
bit "reflection". 

Now that I understand the need for bit reflection (taken into account in the
rocksoft parameterized CRC generator by setting the in and out reflection
flag parameters to TRUE) I am not sure I agree that we want it in iSCSI. The
penalty for full conformity with ethernet seems too great. If people feel
strongly that we must keep the bit reflection I think that to make the
existing documentation clear and unambiguous we would need to explicitly
show the mapping of bits in the iSCSI PDU to coefficients of the message
polynomial that represents the iSCSI PDU. We would also need to show the
mapping of the CRC bits to the coefficients of its representative
polynomial. 

If you don't agree I will elaborate further later this week to try to
convince you. My objective is to be able to easily and unambiguously
describe the polynomial math behind the algorithm; right now, with the bit
reflection and without the explicit mapping it is awkward.

Vince  

---