RE: [Tsvwg] sctp error check

["Douglas Otis" <[e-mail]>]

Randall,

I do not think I was clear about the inverted store and the reflected
results.  The CRC algorithm for Ethernet does a unitary inversion of the CRC
results before storing.  With the CRC being placed in the header, it is my
understanding reasons for doing such an inversion is removed by this header
position.  That was item (3) and has nothing to do with byte order.

For item (4) the reflected table (Meaning that bit 31 is at bit 0, etc.)
used to generate the CRC creates a reversed byte order.  (The reversed bit
order is to be retained.)  This becomes difficult in that there is no
standard routine for placing this reversed byte order into network order.
If we wish to store this result in the correct order, then a new library
routine for doing so becomes required.  If we define the results stored as
"reflected" then the standard htonl() routine can be used otherwise a new
routine such as flip_htonl() needs to be created.  It would look something
like:

#ifdef (LITTLE_ENDIAN)
#define htonl(x) swab32(x)
#define ntohl(x) swab32(x)
#define flip_htonl(x) _u32(x)
#define flip_ntohl(x) _u32(x)
#else
#define htonl(x) _32(x)
#define ntohl(x) _32(x)
#define flip_htonl(x) swab(x)
#define flip_ntohl(x) swab(x)
#endif

Doug

> Doug/All:
>
> I will start a straw poll on the poly after the labor
> day holiday.. I think to many people are away this week
> to get any meaningful indication...
>
> Other comments below..
>
> Douglas Otis wrote:
> >
> > Lyndon,
> >
> > We can do this one issue at a time or attempt to do a few things in
> > parallel.
> >
> > I would prefer the (1) CRC-32c, (2) all one's initialization of
> the CRC, and
> > (3) non-inverted store.
>
> Doug, I don't mind 1 or 2... thats fine... As far as 3 goes, all
> things on the wire must be in Network byte order...
>
> R
>
> >
> > The other issue that remains open would be the (4) byte order
> the reflected
> > CRC value is stored.  To put this information into the normal order, a
> > routine such as flip_ntohl() would need to be added to the
> library and would
> > benefit little endian processors.
> >
> > Doug
> >
> > > I have no preference on the particular CRC, but I agree with
> > > Andreas that we should try to settle this issue.
> > >
> > > Cheers,
> > >
> > > Lyndon
> > >
> > > At 03:26 PM 8/29/2001 +0200, Andreas Jungmaier wrote:
> > > >-----BEGIN PGP SIGNED MESSAGE-----
> > > >Hash: SHA1
> > > >
> > > >Dear all, hi Randy,
> > > >
> > > > > We, as of now, only need to pick the poly.... for the
> > > > > most part I think the only issue is
> > > > >
> > > > > CRC-32/ITU or CRC-32c
> > > > >
> > > >
> > > >Randy, would you take on another straw poll, in order to
> > > >get this (overlong) thread finally settled now ?!
> > > >
> > > >For the reasons given in the draft
> > > >http://www.ietf.org/internet-drafts/draft-sheinwald-iscsi-crc-00.txt
> > > >please count me in favor of *CRC-32-C*
> > > >
> > > >Best regards,
> > > >Andreas
> > > >- --
> >
> > _______________________________________________
> > tsvwg mailing list
> > [e-mail]
> > http://www1.ietf.org/mailman/listinfo/tsvwg
>
> --
> Randall R. Stewart
> [e-mail] 815-342-5222 (cell phone)
>
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>


_______________________________________________
tsvwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/tsvwg