iSCSI Digests

["Julian Satran" <Julian_Satran@il.ibm.com>]

Dear colleagues,

As it was discussed on the list - the standard digests (CRC32C) are now 
being only for integrity and it makes sense to move their negotiation in 
the Operational Negotiation stage of login.

The text for the appendix section should look like:

01      HeaderDigest and DataDigest

Use: IO
Who can send: Initiator and Target

HeaderDigest = <list-of-options>
DataDigest = <list-of-options>

Digests enable checking end-to-end data integrity beyond the integrity 
checks provided by the link layers and covering the whole communication 
path including all elements that may change the network level PDUs like 
routers, switches, proxies, etc. 

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     | Generator |
+---------------------------------------------+
| CRC32C        | 32 bit CRC      |0x11edc6f41|
+---------------------------------------------+
| none          | no digest                   |
+---------------------------------------------+

The generator polynomial for this digest is given in hex-notation, for 
example 0x3b stands for 0011 1011 - the polynomial x**5+X**4+x**3+x+1.

When Initiator and Target agree on a digest, this digest MUST be used for 
every PDU in Full Feature Phase.

Padding bytes, when present, in a segment covered by a CRC, should be set 
to 0 and are included in the CRC. The CRC should be calculated as follows:

- data are assumed to be  in the numbering order that appears in the draft 
- start with byte 0 bit 0 continue byte 1 bit 0 etc. (Big Endian on bytes 
/ Little Endian on bits)
- the CRC register is initialized with all 1s (equivalent to complementing 
the first 32 bits of the message)
- the n PDU bits are considered coefficients of a polynomial M(x) of order 
n-1, with bit 0 of byte 0 being x^(n-1)
- the polynomial is multiplied by x^32 and divided by G(x)- the generator 
polynomial - producing a remainder R(x) of degree <= 31
- the coefficients of R(x) are considered a 32 bit sequence
- the bit sequence is complemented and the result is the CRC
- after the last bit of the original segment the CRC bits are transmitted 
with x^31 first followed by x^30 etc. ( whenever examples are given the 
value to be specified in examples follows the same rules of representation 
as the rest of this document)
- a receiver of a "good" segment (data or header) built using the 
generator 0x11edc6f41 will end-up having in the CRC register the value 
0x1c2d19ed (this a register value and not a word as outlined in this 
draft)

Proprietary algorithms MAY also be negotiated for digests. Whenever a 
proprietary algorithm is negotiated, "none" or "CRC32C" should be listed 
as an option in order to guarantee compatibility


Comments?

Julo