Re: iSCSI: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI

[Paul Koning <ni1d@arrl.net>]

>>>>> "Luben" == Luben Tuikov <ltuikov@yahoo.com> writes:

 Luben> --- Paul Koning <ni1d@arrl.net> wrote:
 >>  I agree that the current description is not consistent and is
 >> confusing.  That's why I proposed replacement text.  I'd be
 >> interested in comments on that text.

 Luben> I gave you a comment in my last letter:

 Luben> Please also note that the Ethernet spec CRC algorithm, is an
 Luben> optimized version of a basic prefix-postfix-initialize-the-
 Luben> CRC-register-to-some-constant algoritm. BUT as SMD it operates
 Luben> on NON-AUGMENTED messages. FOR THAT REASON you cannot say that
 Luben> we have to multiply M(x) by x^32!!!

 Luben> You see, you cannot say that the message has to be multiplied
 Luben> by x^32, if you are describing the Ethernet CRC algo.

 >> Please also note that the Ethernet spec CRC
 >> algorithm, is an
 >> optimized version of a basic
 >> prefix-postfix-initialize-the-
 >> CRC-register-to-some-constant algoritm.
 
 >  I'm not sure what spec you're talking about.

 Luben> The one you always mention, the one you quote in you
 Luben> messages. The one iSCSI is trying to present.

I don't think so.

The one I'm always quoting from says the following (section 6.2.4,
page 30):

  Mathematically, the CRC value corresponding to a given frame is
  defined by the following procedure:

  1. The first 32 bits of the frame are complemented.

  2. The n bits of the frame are then considered to be the
  coefficients of a polynomial M(x) of degree n-1.  (The first bit of
  the destination address field corresponds to the x^(n-1) term and
  the last bit of the data field corresponds to the x^0 term.)

  3. M(x) is multiplied by x^32 and divided by G(x), producing a
  remainder R(x) of degree <= 31.

  (rest omitted)

So as you can see, the statement about multiplying the message by x^32
is taken directly from the Ethernet spec.  That is why I put it into
my proposed text.

Your statement that "you cannot say that the message has to be
multiplied by x^32, if you are describing the Ethernet CRC algo" is
clearly not correct.

The text in my proposed replacement text is the Ethernet text, except
for some terminology and context changes (like "PDU" instead of
"frame") and a slightly different but equivalent way of stating bit
order).

	paul