RE: iSCSI: Nailing down CRC-32C

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Since we are operating over IP, I would think ordering should be "network
order" (Big endian).

Marj 

> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Monday, May 07, 2001 1:00 PM
> To: julian_satran@il.ibm.com
> 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
>