SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Nailing down CRC-32C



    
    
    Mark,
    
    My basic assumption was that everything is (as in all IP related standards)
    in network order.
    
    Regards,
    Julo
    
    
    
    Mark Bakke <mbakke@cisco.com> on 07-05-2001 23:00:28
    
    Please respond to Mark Bakke <mbakke@cisco.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    Subject:  Re: iSCSI: Nailing down CRC-32C
    
    
    
    
    Julian-
    
    That's great; it covers nearly everything.  The only thing left
    is the byte order; are they taken in the same order Ethernet uses?
    
    If so, I can generate a few test patterns that our implementations
    can all check against.
    
    Thanks,
    
    --
    Mark
    
    julian_satran@il.ibm.com wrote:
    >
    > The CRC part of the appendix (for 07) reads:
    >
    >    The following table lists cyclic integrity checksums that can be
    >    negotiated for the digests and MUST be implemented by every iSCSI
    >    initiator and target. Note that these digest options have only error
    >    detection significance.
    >
    >    +---------------------------------------------+
    >    | Name          | Description                 |
    >    +---------------------------------------------+
    >    | crc-32C       | 32 bit CRC      | 11EDC6F41 |
    >    +---------------------------------------------+
    >    | none          | no digest                   |
    >    +---------------------------------------------+
    >
    >    The generator polynomials for those digests are given in hex-notation,
    >    for example 3a stands for 0011 1010 - the polynomial
    x**5+X**4+x**3+x+1.
    >
    >    The generator polynomial selected is evaluated in [Castagnioli93].
    >    When using the CRC the CRC register must be initialized to all 1s
    >    (0xFFFFFFFF) and the CRC bits must be complemented before
    transmission.
    >    Padding bytes, when presents in a segment covered by a CRC, have to be
    >    set to 0 and are included in the CRC.
    >
    >    Regards,
    >    Julo
    >
    > Mark Bakke <mbakke@cisco.com> on 05-05-2001 00:13:09
    >
    > Please respond to Mark Bakke <mbakke@cisco.com>
    >
    > To:   IPS <ips@ece.cmu.edu>
    > cc:
    > Subject:  iSCSI: Nailing down CRC-32C
    >
    > At the interim meeting, it was stated that iSCSI has selected
    > the CRC-32C polynomial as its required iSCSI-level header and
    > data CRC.  Now that we have it, it's time to move on and make
    > sure we can implement it.
    >
    > In the interest of interoperability, we need to not only specify
    > the polynomial, but also the initial values, bit and byte
    > ordering, etc.
    >
    > "A Painless Guide to CRC Error Detection Algorithms"
    > (http://www.ross.net/crc/crcpaper.html) specifies a
    > method to unambiguously characterize these parameters
    > (sections 15 and 16).  Has anyone taken a shot at defining
    > these yet?  Otherwise, here is what it might look like:
    >
    > Name   : "CRC-32C"
    > Width  : 32
    > Poly   : 1EDC6F41   (note that the leading "1" is implied)
    > Init   : FFFFFFFF
    > RefIn  : True
    > RefOut : True
    > XorOut : FFFFFFFF
    > Check  : ?
    >
    > I haven't attempted to create check data based on these yet.  As
    > soon as the other parameters are nailed down, we need to do this.
    >
    > Anyway, I am not a CRC expert, and can't make any statement about
    > the above values being the "best" way to do this, but instead just
    > copied them (except the polynomial itself) from the Ethernet CRC,
    > since that is likely the easiest for everyone implementing hardware
    > to deal with.
    >
    > If someone else is already doing this, let me know; I just wanted
    > to start this thread so we can get closure.
    >
    > Regards,
    >
    > Mark
    >
    > --
    > Mark A. Bakke
    > Cisco Systems
    > mbakke@cisco.com
    > 763.398.1054
    
    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:45 2001
6315 messages in chronological order