SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Nailing down CRC-32C



    
    Assumptions:
    
    1) The iSCSI DATA PDU Header and Data Integrity checks uses CRC-32
    2) Support of Integrity check is mandatory for both header and Data 
       digest
    3) An iSCSI PDU may span multiple TCP segments. 
    4) Any of these segments may arrive out of order at the receiver.
    5) To regenerate the CRC for comparison with the value present in the 
    PDU received, the receiver needs to keep in a temporary buffers all 
    segments, waiting for the missing one, as CRC must be computed using 
    the whole re-assembled PDU
    
    Question: Does CRC-32 support partial computation and compensation 
    for wrong initial values later (I guess NO!), to enable partial CRC 
    calc on avail parts of PDU?
    
    
    Possible answer: No
    
    Possible Conclusion: The RCV side is further complicated b/c of this 
    CRC
    
    Possible solutions:
    
    1) Use CRC that allows partial calc
    2) Limit iSCSI PDU to TCP MSS if data CRC is used (added o/h)...
    3) Leave as it, though it has cost , performance implication and hurts
    scaling to 10G..
    
    
    Nima
    
    
    
    -----Original Message-----
    From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
    Sent: Saturday, May 05, 2001 9:21 AM
    To: ips@ece.cmu.edu
    Subject: Re: iSCSI: Nailing down CRC-32C
    
    
    
    
    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
    
    
    
    
    
    
    
    
    
    
    _______________________________________________________
    Send a cool gift with your E-Card
    http://www.bluemountain.com/giftcenter/
    
    
    


Home

Last updated: Tue Sep 04 01:04:45 2001
6315 messages in chronological order