|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Nailing down CRC-32CMark, I have attempted to provide a reference implementation for SCTP in this draft. Ignore all but the CRC algorithm. ftp://ftp.sanlight.net/pub/draft-otis-sctp-digest-01.txt Doug > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark Bakke > Sent: Thursday, June 07, 2001 7:48 AM > To: Venkat Rangan > Cc: 'julian_satran@il.ibm.com'; ips@ece.cmu.edu > Subject: Re: iSCSI: Nailing down CRC-32C > > > Venkat- > > Sorry for the high-latency response; it took a while to > get back to this thread. Anyway, I don't see any particular > reason why the bit ordering has to be one way or the other, > except that it will be easier for everyone if we do the > reflection both in and out, since it will match what is > done on Ethernet, Fibre Channel, and ultra-SCSI. Looking > at these documents, I think that the simplest and least > ambiguous description of the CRC is in the T10 SPI-3 > (rev 14, page 121). It includes a description of the > bit ordering, as well as a few simple test cases. It's > at: > > ftp://ftp.t10.org/t10/drafts/spi3/spi3r14.pdf > > Julian, I think that the last data integrity section you > had sent covers everything except the bit ordering. If we > copied the statement: > > Bytes are bit reversed prior to generating the remainder > and the bytes of the remainder are bit reversed prior to > forming the CRC field. > > from the T10 doc, I think that everything else is specified. > > It would then be helpful as a check to include a few test > cases that people could run. I took the T10 test cases, and > ran them through with (my interpretation of) the iSCSI > CRC-32C: > > For a 32-byte transfer of all 00h, the CRC will be 8A9136AA > (the most significant byte would be the first byte transmitted > on the network interface). > > For a 32-byte transfer of all FFh, the CRC will be 62A8AB43. > > For a 32-byte incrementing test pattern of bytes starting with > 00h and ending with 1Fh, in network order, the CRC will be > 46DD794E. > > This should be sufficient for someone to test their hardware > or software implementation of the iSCSI CRC, and ensure that > it will be interoperable. If desired, we could also make up > a sample iSCSI header (perhaps an inquiry command or something > equally common), along with its expected CRC. > > Can we add the above statements on bit ordering and test cases > to the draft-07? It will give us the best possible chance of > everyone's implementation of the CRC to match the first time. > > -- > Mark > > Venkat Rangan wrote: > > > > Mark, > > > > Is there any specific advantage to iSCSI Reflection Parameters > > to be different from that of Ethernet? Does CRC32-C benefit by > > a different set of parameters? If so, what are they, and how do we > > get closure on a particular set of parameters? > > > > Purely from the description of the parameters, RefIn=TRUE means > that each > > byte from the stream is 'reflected' so that bit 0 is fed in first and > > then bit 1 etc. RefOut=TRUE means that the 32-bit value of the > CRC is also > > reflected before the final XOR is done. > > > > Currently, Ethernet has 'RefIn=TRUE' and 'RefOut= TRUE'. > > > > Thanks, > > > > Venkat Rangan > > Rhapsody Networks Inc. > > http://www.rhapsodynetworks.com > > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Tuesday, May 15, 2001 5:16 AM > > To: Venkat Rangan > > Cc: 'julian_satran@il.ibm.com'; ips@ece.cmu.edu > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > Venkat- > > > > I assumed the same parameters (iSCSI has not yet specified > > the reflection parameters), and obtained the same check you > > did with their code. > > > > -- > > Mark > > > > Venkat Rangan wrote: > > > > > > All, > > > > > > Based on the finalization of the parameters of CRC-32C per following > > > parameters, I obtained a check of 0xE3069283 for the > nine-byte string of > > > "123456789" (9 bytes) that the Rocksoft CRC document refers to. > > > > > > Name : "CRC-32C" > > > Width : 32 > > > Poly : 1EDC6F41 (note that the leading "1" is implied) > > > Init : FFFFFFFF > > > RefIn : True > > > RefOut : True > > > XorOut : FFFFFFFF > > > Check : E3069283 > > > > > > It would be nice if other independant checks can validate this. > > > > > > Venkat Rangan > > > Rhapsody Networks Inc. > > > http://www.rhapsodynetworks.com > > > > > > The table and code follows: > > > > > > /*****************************************************************/ > > > /* */ > > > /* CRC LOOKUP TABLE */ > > > /* ================ */ > > > /* The following CRC lookup table was generated automagically */ > > > /* by the Rocksoft^tm Model CRC Algorithm Table Generation */ > > > /* Program V1.0 using the following model parameters: */ > > > /* */ > > > /* Width : 4 bytes. */ > > > /* Poly : 0x1EDC6F41L */ > > > /* Reverse : TRUE. */ > > > /* */ > > > /* For more information on the Rocksoft^tm Model CRC Algorithm, */ > > > /* see the document titled "A Painless Guide to CRC Error */ > > > /* Detection Algorithms" by Ross Williams */ > > > /* (ross@guest.adelaide.edu.au.). This document is likely to be */ > > > /* in the FTP archive "ftp.adelaide.edu.au/pub/rocksoft". */ > > > /* */ > > > /*****************************************************************/ > > > > > > unsigned long crctable[256] = > > > { > > > 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, > > > 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, > > > 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, > > > 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, > > > 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, > > > 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, > > > 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, > > > 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, > > > 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, > > > 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, > > > 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, > > > 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, > > > 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, > > > 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, > > > 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, > > > 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, > > > 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, > > > 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, > > > 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, > > > 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, > > > 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, > > > 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, > > > 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, > > > 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, > > > 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, > > > 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, > > > 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, > > > 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, > > > 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, > > > 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, > > > 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, > > > 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, > > > 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, > > > 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, > > > 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, > > > 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, > > > 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, > > > 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, > > > 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, > > > 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, > > > 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, > > > 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, > > > 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, > > > 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, > > > 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, > > > 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, > > > 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, > > > 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, > > > 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, > > > 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, > > > 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, > > > 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, > > > 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, > > > 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, > > > 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, > > > 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, > > > 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, > > > 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, > > > 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, > > > 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, > > > 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, > > > 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, > > > 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, > > > 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L > > > }; > > > > > > /*****************************************************************/ > > > /* End of CRC Lookup Table */ > > > /*****************************************************************/ > > > > > > /*****************************************************************/ > > > /* ComputeCRC */ > > > /*****************************************************************/ > > > #include <stdio.h> > > > #include <stdlib.h> > > > #include "crctable.h" > > > > > > #define TB_INIT 0xFFFFFFFF > > > #define TB_INIT_REFLECTED 0xFFFFFFFF > > > #define TB_XOROT 0xFFFFFFFF > > > > > > unsigned long crc_reflected (); > > > unsigned long crc_reflected (blk_adr,blk_len) > > > unsigned char *blk_adr; > > > unsigned long blk_len; > > > { > > > unsigned long crc = TB_INIT_REFLECTED; > > > while (blk_len--) > > > crc = crctable[(crc ^ *blk_adr++) & 0xFFL] ^ (crc >> 8); > > > return crc ^ TB_XOROT; > > > } > > > > > > -----Original Message----- > > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > > > Sent: Tuesday, May 08, 2001 7:38 AM > > > To: ips@ece.cmu.edu > > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > > > 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 > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 >
Home Last updated: Tue Sep 04 01:04:32 2001 6315 messages in chronological order |