|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: [Fwd: Crc-32c example in iSCSI spec]Mark, I agree that for iSCSI there is no technical advantage to the bit order chosen for the CRC. Bit order through the CRC checker helps in serial data transmission such as over an Ethernet. If the bits are checked in the same order as they are transmitted, then they will get the full length of burst error detection. If they aren't, then burst error protection can shrink about in half. When iSCSI packets are on an Ethernet, the Ethernet CRC provides this protection. The iSCSI CRC protects the packet when it isn't on the LAN and, in that case, it is often moving byte parallel and when it is moving serial the bytes might be sent in either order. The important thing is that the order be specified clearly so everyone does the same thing. Regards, Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Friday, August 17, 2001 10:06 AM To: Sanjay Goyal Cc: Ips (E-mail) Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec] 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
Home Last updated: Tue Sep 04 01:03:59 2001 6315 messages in chronological order |