Re: iSCSI : Reject PDU reserved fields.

[Santosh Rao <santoshr@cup.hp.com>]

> All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject
> PDU
> carries an invalid ITT which will not be 0xFFFFFFFF - most probably
> 0x00000000.
> As of today, an initiator has to be sure the PDU is not a Reject PDU
> to
> interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this
> test.


The above is'nt sufficient in itself. The word 4 (ITT position in other
PDUs) in the Async PDU also does not contain the ITT field and is set to
reserved. (0).

If we're adding the ITT field (and requiring it to be 0xFFFFFFFF) in
word 4 of the Reject PDU, it also needs to be added to the Async pdu.

Regards,
Santosh


Julian Satran wrote:
> 
> I think we may want to do this.
> 
> Julo
> 
>  Gwendal Grignou
>  <ggrignou@silverbacksystems.com>                 To:        iSCSI
>  Sent by: owner-ips@ece.cmu.edu           <ips@ece.cmu.edu>
>                                                   cc:
>  20-02-02 00:40                                   Subject:
>                                            iSCSI : Reject PDU
>                                           reserved fields.
> 
> 
> 
> Hello,
> 
> I wonder if it would be possible to have the 4 bytes word at offset
> 16-19 set
> to 0xFFFFFFFF in case of a Reject PDU.
> All iSCSI PDU either carries a valid ITT or 0xFFFFFFFF. Only Reject
> PDU
> carries an invalid ITT which will not be 0xFFFFFFFF - most probably
> 0x00000000.
> As of today, an initiator has to be sure the PDU is not a Reject PDU
> to
> interpret the ITT. By setting the ITT to 0xFFFFFFFF, we avoid this
> test.
> 
> Gwendal.

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################