SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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


    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




Home

Last updated: Thu Jun 06 17:18:37 2002
10554 messages in chronological order