|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI CRC inconsistencyI did it already for CRC - it will appear tomorrow on 12-97 - Julo
Julian, I concur with Pat's request for explicit mapping of the bits of the remainder polynomial to the bits of the CRC. I had pointed out the need for such explicit mapping, to resolve ambiguity in the process, in a memo on Aug 22, 2001. In that memo I also objected to the bit reflection but I later retracted that objection. I also outlined, in a memo on Nov. 27, 2001, how I would describe the CRC process at the transmitter and receiver to resolve the ambiguity. The particular step in the process that Pat pointed out is missing from the iSCSI spec, is the reversing of bits (bit reflection) within each byte of the remainder of the modular division. As Pat pointed out, the examples shown in the spec *do* assume this bit reversal, but the process steps in the spec seem to indicate no bit reversal. The wording that Pat is recommending seems accurate to me and is a good alter! native to what I had suggested. Regards, Vince -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Wednesday, June 05, 2002 10:29 AM To: Julian_Satran@il.ibm.com; pat_thaler@agilent.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI CRC inconsistency 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
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 Message-ID: <FEEBE78C8360D411ACFD00D0B74779719A892C@xsj02.sjs.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> To: 'Julian Satran' <Julian_Satran@il.ibm.com>, 'Mark Bakke' <mbakke@cisco.com> Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com>, "'Pat.Thaler@d12relay01.de.ibm.com'" <Pat.Thaler@d12relay01.de.ibm.com>, "'ips@ece.cmu.edu'" <ips@ece.cmu.edu> Subject: RE: iSCSI CRC: A CRC-checking example Date: Wed, 22 Aug 2001 11:42:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C20D9E.520490E0" 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 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF705@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> To: 'Luben Tuikov' <ltuikov@yahoo.com> Cc: "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>, "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>, "CAVANNA,VICENTE V (A-Roseville,ex1)" <vince_cavanna@agilent.com> Subject: Re: iSCSI v8 CRC32c Date: Tue, 27 Nov 2001 19:39:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C20D9E.520490E0" 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 has been removed from this note on June 07 2002 by Julian Satran
Home Last updated: Thu Jun 06 20:18:47 2002 10561 messages in chronological order |