Title: 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
Title: Re: iSCSI v8 CRC32c
Luben,
Your questions may have already been answered by Paul Koning who has apparently reviewed your code in detail but attached, as I promised, is a Mathematica worksheet (pdf format) that produces results consistent with the iSCSI spec. You do not need to know the syntax of Mathematica in order to follow the process, as I have inserted lots of comments.
The example I describe uses, as data, 32 decrementing bytes. This is one of hte test cases in the iSCSI document. I have added an undetectable error pattern which does not change the results obtained at the receiver. I think it would be useful to include, in the iSCSI document, such an undetectable error pattern.
I am considering writing an informative Internet Draft describing the process. I would incorporate the contents of the attached worksheet and also explain the theory behind the process. This should answer such questions as why is the expected remainder at the receiver the constant 1c 2d 19 ed in hex. If you or others have suggestions let me know.
For those not interested in the math I summarize the process below.
Vicente Cavanna
Agilent Technologies
The symbols I use:
------------------
G is the iSCSI CRC32c polynomial.
L32 is the order-32 poly represting all 1s.
F is the poly representing 32 decrementing bytes which I will use as my test data.
ReflectedF is the poly representing F, after reversing the order of bits within each byte.
R is the remainder of the division performed at the transmitter.
ReflectedR is the poly obtained by reversing the order of bits within each byte of R.
FCS is the complement of ReflectedR. This is the CRC that you would compare with the iSCSI document. In the case of this example of 32 decrementing bytes the FCS is a7 e4 e4 ae in hex.
M is the transmitted message before injecting errors.
Error is the error pattern that I add to M. I use G+x^5*G after applying reflection. Any linear combination of Gs will similarly be undetected.
M* is the received message.
ReflectedM* is M* with the order of bits within each byte reversed.
Rec is the computed CRC at the receiver. You would expect 1c2d19ed in the absence of errors or if error pattern is undetectable as is the case in my example.
The process, for the case of no errors, is as follows:
------------------------------------------------------
At the transmitter:
----------------------
F is the data.
Reverse bits within each byte of F to obtain ReflectedF.
Shift ReflectedF left by 32 positions.
Add 1's to most significant 32 bits of the result (implemented by initializing CRC register to 1's).
Divide by G to obtain the 32 bit remainderR. Note that R is not the CRC shown in iSCSI document!
Reverse bits within each byte of R to obtain ReflectedR.
Add 32 1's to the result to obtain the FCS (implemented by complementing). This is what is shown in the iSCSI document and, for this example, is a7 e4 e4 ae in hex.
Form the transmitted message, M, by shifting F left by 32 positions and adding FCS. Note that M is derived from F rather than from ReflectedF even though the FCS is computed from ReflectedF.
M* is hte same as M since we are not introducing errors here. See the Mathematica worksheet for the case with (undetectable) errors.
At the receiver:
----------------
Receive M*
Reverse bits within each byte of M* to obtain ReflectedM*.
Shift the result left by 32 positions.
Add 1's to most significant 32 bits of result (implemented by initializing CRc to 1's).
Divide by G to obtain the remainder, Rec. The result (for the case of no errors) is expected to be the constant 1c 2d 19 ed in hex.
In the Mathcad worksheet I actually introduce an undetectable error pattern, G+G*x^5, which I reflect and add to M to obtain M*. The rest is the same. Note that the error must also be "reflected". See the worksheet for details.
<<TestingCRC32cDecrBytePattern.pdf>>
TestingCRC32cDecrBytePattern.pdf
