Re: iSCSI: Nailing down CRC-32C

[julian_satran@il.ibm.com]

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