Re: iSCSI: Nailing down CRC-32C

[Steve Senum <ssenum@cisco.com>]

The bit order within a byte also needs to be specified.

Steve Senum

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> 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
> >