RE: iSCSI CRC: A CRC-checking example

["Julian Satran" <Julian_Satran@il.ibm.com>]

Vince & all,

I've added some statement about order (byte and bit) to the draft (you have
probably missed that piece of the mail).

I could be more graphic and less explicit as in SPI but I think that won't
help too much.

People did it for ethernet for years without too much ado.

And don't complain to me - IBM did consistent bit ordering for years
(Big-endian).  IBM even sent ASCII big endian (nobody else did and we had
to recode for VT100 access).

As for what to choose - It seems that we are in an are where almost
everybody does it now in this crazy way.
I strongly suspect that this was also the reason for the way SPI does it.
They have gone all the way to acommodate
x86 byte ordering in registers - so that the revert the bytes before
calculating -and do this on a parallel bus!
360 was certainly the last bastion of regularity.

Regards,
Julo


"CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> on
22-08-2001 20:42:50

Please respond to "CAVANNA,VICENTE V (A-Roseville,ex1)"
      <vince_cavanna@agilent.com>

To:   Julian Satran/Haifa/IBM@IBMIL, "'Mark Bakke'" <mbakke@cisco.com>
cc:   "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>,
      Pat.Thaler@d12relay01.de.ibm.com, ips@ece.cmu.edu
Subject:  RE: iSCSI CRC: A CRC-checking example



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