SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI CRC: A CRC-checking example



    The last line says
     "but I suppose it is advantageous to do
    things the ethernet way."
    May I know in what ways it would be advantageous.
    
    Regards
    Sanjay Goyal
    
     
    
    -----Original Message-----
    From: CAVANNA,VICENTE V (A-Roseville,ex1)
    [mailto:vince_cavanna@agilent.com]
    Sent: Thursday, August 23, 2001 1:55 PM
    To: 'Douglas Otis'; CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
    Cc: 'Mark Bakke'; ips@ece.cmu.edu; 'Steve Blightman'; THALER,PAT
    (A-Roseville,ex1)
    Subject: RE: iSCSI CRC: A CRC-checking example
    
    
    Doug,
    
    If the transmit side CRC generator used for the frame check sequence the
    remainder of the polynomial division directly (without complementing) the
    receiver-side CRC checker would be expected to end up with zeroes after
    processing an error-free frame. Unfortunately the receiver side CRC checker
    would also end up with zeroes after processing a frame whose only "errors"
    are extra trailing zeroes. Thus this type of error would not be detected by
    the CRC checker.
    
    Note that the expected final state of the receiver-side CRC checker is
    expected to be zero if hte remainder is not complemented even though both
    transmit and receiver sides initialize their CRC register to 1s. It is the
    operation of complementing the remainder that causes the receiver to have a
    non-zero (but constant) ending state after processing an error-free frame.
    
    If I understand you correctly, you have described another type of error that
    would be undetected were the remainder not complemented. Whenever the
    receiver CRC register is in its zero state (perhaps partially through a
    packet) the receiver checker would be blind to extra zeroes inserted in the
    packet at that point. I agree.
    
    Again, the improved protection resulting from initializing the CRC to 1s and
    complementing the remainder is not important for iSCSI because the packet
    length can be checked independently but I suppose it is advantageous to do
    things the ethernet way.
    
    
    Vince
    
    |-----Original Message-----
    |From: Douglas Otis [mailto:dotis@sanlight.net]
    |Sent: Wednesday, August 22, 2001 5:48 PM
    |To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
    |Cc: 'Mark Bakke'; ips@ece.cmu.edu; 'Steve Blightman'; THALER,PAT
    |(A-Roseville,ex1)
    |Subject: RE: iSCSI CRC: A CRC-checking example
    |
    |
    |Vince,
    |
    |Thanks for the explanation and here is how I understand your 
    |comments.  Even
    |with the CRC unlikely to find zero as a stable state with the all ones
    |initialization, in a rare event where a CRC value becomes zero over a
    |trailing list of zeros, then an inverted CRC store will create 
    |an all ones
    |as an ending value.  This is to better ensure detection of the 
    |end of the
    |block as there are encoding changes that help the underlying decoding
    |process.  It would seem that there is still the requirement to 
    |know the end
    |of the frame regardless of the CRC value but there may be an 
    |advantage to
    |this encoding change.  Again, thanks.
    |
    |Doug
    |
    |
    |> In answer to Doug's question about the reason for using the 
    |COMPLEMENT of
    |> the remainder of the division as the CRC ....
    |>
    |> One reason I recall, is that this method permits the 
    |receiver to detect
    |> extra trailing zeroes in the protected packet. If the 
    |remainder were sent
    |> directly as the CRC, in the absence of errors the remainder 
    |of a similar
    |> computation at the receiver would be expected to be zero. 
    |This means that
    |> errors consisting of extra trailing zeroes would not be 
    |caught since zero
    |> input bits would cause no changes in the CRC circuit once 
    |the CRC register
    |> is in the so called "inaccessible state" consisting of all zeroes.
    |
    


Home

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