Re: iSCSI: Nailing down CRC-32C

[Mark Bakke <mbakke@cisco.com>]

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