RE: iSCSI CRC inconsistency

[pat_thaler@agilent.com]

Julian,

 

Yes, magic number is stated in polynomial order and the accompanying text says that so I have no

problem with the magic number text.

 

It is only the description of how the CRC is placed into the message that needs correction/clarification.

As you say, hypothetical wire order is not relevant. We need to specify with respect to iSCSI's defined

word order.

 

Regards,

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 05, 2002 10:21 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI CRC inconsistency

Pat, 

I was referring to a hypothetical wire 
order and that matches the order I stated in the first list element. 
I will try to map it to the word order as the 
wire order is not relevant anyhow. 
The 
magical number is however a polynomial and not a word mapping. 

Julo

pat_thaler@agilent.com 06/04/2002 11:31 PM Please respond to pat_thaler

To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu         cc:                 Subject:        iSCSI CRC inconsistency

Julian,

There is an inconsistency in the description of the CRC32. 
In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
- 
The CRC bits appear after the message bits with x^31 first
followed by x^30 
etc. (when examples are provided, the value
to be specified in the examples 
follows the same
ordering as the rest of this document).

At the top of 
the next page, it describes the magic number CRC check where one runs the CRC 
generator over the data or header plus the received digest and gets the magic 
number:
- A receiver of a "good" segment (data or header) including 
the
CRC built using the generator 0x11edc6f41 will get the 
value
0x1c2d19ed as its CRC (this is a polynomial value and not a
word as 
outlined in this draft).

The point of the magic number algorithm is that 
it uses exactly the same algorithm to check the CRC that was used to generate 
the CRC. When running the check, the received CRC is run through the generator 
with the same bit order as the covered data. Therefore, this check only works 
right when the CRC is appended to the data using the same bit ordering within a 
word as was used when sending the covered data through the CRC generator. The 
examples in B.4 show the bits ordered as they should be and page 207 is 
inconsistent with them..

Specifically, data bits go through the generator 
from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. 
Therefore, paragraph on how the CRC bits are placed in the field should be:
- 
The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of 
the first byte (byte 0) of the digest continuing to through the byte the x^24 
coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of 
byte 1, etc. (When examples are provided they show the CRC as it appears in the 
PDU with the bit significance used throughout this document. That is, bit 7 of 
each byte is interpreted as most significant though it is the coefficient of the 
lowest order CRC term in the byte.).

I have checked and this order 
matches the examples in 
B.4.

Regards,
Pat