SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI v8 CRC32C



    Hi Luben,
    
    Looks like you are not taking into account the fact that iSCSi assumes that
    the least significant BIT within a byte is transmitted first (whereas the
    most significant BYTE is transmitted first)! Recall that the bit that is
    transmitted first represents the coefficient of the highest order term of
    the message polynomial. The reason for this strange behavior is the desire
    to be consistent with Ethernet. It seems this detail of ethernet CRC was not
    realized by many but fortunately has been captured in a parameter called
    "bit reflection flag" in a popular CRC tool that many are using.
    
    See also the attached email that I sent to the reflector in August wherein I
    objected, though not strongly, to copying Ethernet to such a degree. I
    subsequently yielded when it was claimed that Ethernet implementors managed
    to cope with the potential source of confusion and the benefits of being
    consistent outweighed the problems. Eventually we will learn to cope too
    :-).
    
    If you want a Mathematica worksheet showing the polynomial math behind the
    calculations as well as the required bit/byte mappings ask me and I will dig
    it up - after the Holidays. I was going to publish it to the reflector but
    don't have the time to put it in a more acceptable format.
    
    Vince
    
    
    -----Original Message-----
    From: Luben Tuikov [mailto:ltuikov@yahoo.com]
    Sent: Tuesday, November 20, 2001 1:01 PM
    To: ips@ece.cmu.edu
    Subject: iSCSI v8 CRC32C
    
    
    Hello,
    
    I've been trying to get CRC32C working. I read a few papers,
    derived the equations myself, etc, etc, but still cannot get
    CRC32C to work...
    
    My basic framework is: (not precomputing a table -- just force):
    
    poly= 1edc6f41;
    crc = all 1's;
    while more bits in message do
    	crc shift left, adding the next message bit at right;
    	if carry then
    		crc = crc XOR poly;
    	end if;
    end while;
    crc = NOT crc; (e.g. complement the register)
    
    What is wrong with this implementation?
    
    Thanks,
    -l
    
    
    
    =====
    --
    
    __________________________________________________
    Do You Yahoo!?
    Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
    http://geocities.yahoo.com/ps/info1
    
    


    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  
    
    




Home

Last updated: Tue Nov 27 21:17:43 2001
7923 messages in chronological order