Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]

[Mark Bakke <mbakke@cisco.com>]

Sanjay Goyal wrote:
> 
> Hi
>  I get the remainder for iSCSI as 0x1c2d19ed if I complement my CRC and then
> pass it through the CRC engine.
>
>  As per CRC generation for data: the thing which is not clear to me is
>    why do we need to bit-swap the CRC reminader as is done in all your
> examples.

As far as I can tell, bit-swapping does nothing to help or hurt
the effectiveness of the CRC.  When I ran my examples, I thought
that it would be the simplest for our CRC to different from the
Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
all do this, so I figured it would cause the least confusion if
we did the same.

> We can just complement it and append it after the DATA bytes.
>  The other side also can just pass it through the CRC engine to check it.
> 
> Regards
> Sanjay Goyal
> 
> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Thursday, August 16, 2001 1:43 PM
> To: Steve Blightman; ips@ece.cmu.edu
> Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
> 
> One more thing that might be helpful.  When the Ethernet
> polynomial is used in SCSI to generate its CRC, the T10
> doc specifies the remainder polynomial that one should see
> after running the data with a valid CRC through.  For
> the Ethernet CRC, this was specified as 0xc704dd7b.  This
> remainder polynomial is taken before the CRC is complemented
> and bit-reflected.  For iSCSI, I came up with a remainder of
> 0x1c2d19ed.  Can anyone verify this result?
> 
> --
> Mark
> 
> Mark Bakke wrote:
> >
> > Steve-
> >
> > I just ran some Ethernet packets with known CRCs through
> > my iSCSI/Ethernet CRC generator, and found the same thing
> > as you did.
> >
> > All of my examples need to be byte-swapped, along with the
> > fix I already posted for the all-ones example.  Here is a
> > new set of examples, which will be in -08.  I also ran
> > 64 bytes of zeroes and ones, which now agree with your
> > numbers as well.
> >
> > Thanks again for bringing this up.
> >
> > --
> > Mark
> >
> >      07 CRC Examples
> >
> >         N.B. all Values are Hexadecimal
> >
> >           Byte:        0  1  2  3
> >
> >              0:       01 a0 00 00
> >              4:       00 00 00 00
> >              8:       00 00 00 00
> >             12:       00 00 00 00
> >             16:       04 05 00 00
> >             20:       00 01 00 00
> >             24:       00 00 00 05
> >             28:       00 00 00 04
> >             32:       2a 00 00 00
> >             36:       00 00 00 00
> >             40:       80 00 00 00
> >             44:       00 00 00 00
> >
> >            CRC:       93 70 51 db
> >
> >         32 bytes of zeroes:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 00 00 00
> >            ...
> >             28:       00 00 00 00
> >
> >            CRC:       aa 36 91 8a
> >
> >         32 bytes of ones:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       ff ff ff ff
> >            ...
> >             28:       ff ff ff ff
> >
> >            CRC:       43 ab a8 62
> >
> >         32 bytes of incrementing 00..1f:
> >
> >           Byte:        0  1  2  3
> >
> >              0:       00 01 02 03
> >            ...
> >             28:       1c 1d 1e 1f
> >
> >            CRC:       4e 79 dd 46
> >
> >
> > Steve Blightman wrote:
> > >
> > > I believe the examples for the ISCSI CRC  have the wrong endianness.
> > >
> > > As yiou suugested over the phone I ran some Ethernet frames through a
> > > simulation. I have some difficulty running the exact simulations you
> > > wanted becuase the minimum size Ethernet frame is 64 bytes.
> > >
> > > However using the Ethernet CRC polynomial,
> > > Running 64 bytes of 0 onto the wire, we append "36 63 8d 75" onto the
> > > wire for the CRC - "36" goes out first.
> > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the wire - "ba"
> > > goes out first.
> > >
> > > Using the same logic for the ISCSI polynomial
> > > Running 64 bytes of 0 I think we should append "67 eb c8 03" - "67"
> > > going out first
> > > and running 64 bytes of all 1 we should append "66 4e cd 2f" - "66"
> > > going out first
> > >
> > > And now for 32 bytes with the ISCSI polynomial
> > >
> > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa" going out
> > > first
> > > Running 32 bytes of all 1 we should append "43 ab a8 62" - "43" going
> > > out first
> > >
> > > I don't want to get into an endless endian debate, but I believe it is
> > > important to get the order of these bytes in the right order, so that we
> > > can use the same hardware to check as well as to generate CRCs.
> > >
> > > Thanks for your help on this,
> > > Steve Blightman
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 
>   ----------------------------------------------------------------------------------------------------
> 
>    Part 1.2    Type: application/ms-tnef
>            Encoding: base64

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054