Re: [Ips] LUN or reserved in R2T?

[Ming Zhang]

On Sun, 2005-03-06 at 15:34, Nicholas A. Bellinger wrote:
> On Sun, 2005-03-06 at 11:14 -0500, Ming Zhang wrote:
> > >
> > > I have used to rule in the iscsi-initiator-core.org initiator stack
> > > implementation that the Initiator uses the OS'es SCSI Task LUN inside of
> > > the LUN field for DataOUT PDUs in the solicited DataOUT case. This
> > > ensures that the LUN from the original PDU containing the SCSI CDB and
> > > all DataOUT PDUs contain the same value. Please see
> > > iscsi_initiator.c:iscsi_build_data_out() for further details.
> > >
> > This is to say that you are a good guy. :)
> >
> > But does your initiator check the target R2T packet Lun field?
>
> No, and here is the reasoning from 10.7.4:
>
> The Target Transfer Tag values are not specified by this protocol
> except that the value 0xffffffff is reserved and means that the
> Target Transfer Tag is not supplied. If the Target Transfer Tag is
> provided, then the LUN field MUST hold a valid value and be
> consistent with whatever was specified with the command; otherwise,
> the LUN field is reserved.
>
> 'Consistent' here meaning the DataOUT should be using the LUN from the
> original SCSI command PDU, and not what the target may or may not be
> echoing back in an R2T.
as 10.7.4

On incoming data, the Target Transfer Tag and LUN MUST be provided by
the target if the A bit is set to 1; otherwise they are reserved.
The Target Transfer Tag and LUN are copied by the initiator into the
SNACK of type DataACK that it issues as a result of receiving a SCSI
Data-In PDU with the A bit set to 1.

so this A bit should be check first, before checking the validity of LUN
if initiator want to check it.

>
> All good targets MUST include the original LUN from the SCSI command PDU
> when they are soliciting DataOUT with R2Ts as specified in 3.2.4.3:
>
> As the Initiator Task Tag is used to identify a task during its
> execution the iSCSI initiator and target MUST verify that all other
> fields used in task related PDUs have values that are consistent
> with the values used at the task instantiation based on Initiator
> Task Tag (e.g., the LUN used in an R2T PDU MUST be the same as the
> one used in the SCSI command PDU used to instantiate the task).
> Using inconsistent field values is considered a protocol error.
>
> Aside from these two points, it can be argued there is no MUST
> requirement that the Initiator actually _check_ the LUN in the R2T
> against what it originally sent in the SCSI command, only that the LUN
> in solicitied DataOUT PDUs be consistant with the LUN from the original
> SCSI command PDU.
>
> >
> > > On the target side, I have observed in the past that certain initiators
> > > may not include the correct LUN inside of solicited DataOUT PDUs, and
> > > hence cause interopt problems. In the PyX Technologies Target Stack we
> > > leave the check against DataOUT PDU's LUN vs. the original
> > > ISCSI_INIT_SCSI_CMND pdu's LUN stubbed out in order to ensure interopt
> > > with these initiator implementations.
> > >
> > This is to say that you allow other guys to do something not so good. :)
> >
>
> Not really. The initiator knows what LUN its DataOUT is destined for,
> after all, it was the initiator that selected what LUN the original SCSI
> command PDU was directed towards in the first place. I believe this
> example Jonathan B. Postel's famous observation on network protocol
> design:
>
> "Be liberal in what you accept, and conservative in what you send".
>
> > But the question is, what does the rfc say? and which one strictly
> > follows the standard?
> >
>
> Along with the quoted sections from above, here is my interpretation of
> what RFC 3720 says for the WRITE case:
>
> Initiator: The LUN field in ISCSI_INIT_SCSI_CMND and
> ISCSI_INIT_SCSI_DATA_OUT PDUs should be from the same data source (ie:
> the SCSI Task from the Host OS). Since the initiator has the initial
> choice of what LUN the SCSI Command is destined towards, I believe its
> up to the implementor to determine if the LUN from the R2T should be
> checked against the original SCSI Command's LUN. ie: The initiator is
> telling the target what LUN the SCSI Command is destined for, and not
> the target telling the initiator.
>
> Target: The LUNs in the original SCSI command MUST be copied into all
> R2Ts. There is no strict requirement that the Target check the LUN in
> subsequent DataOUT PDUs fullfilling the R2T.
i admit that this is really conservative. :P

thanks.

ming

[Dmitry Yusupov]

Thanks for investigation!

"A" bit is in use for ERL>0. as of today its not used in open-iscsi
initiator. well, anyway. I guess right fix would be:

for open-iscsi: remove checking

for IET: make sure LUN in R2T matching original SCSI Command request.

Regards,
Dima

[Ming Zhang]

On Sun, 2005-03-06 at 23:02, Dmitry Yusupov wrote:
> Thanks for investigation!
>
> "A" bit is in use for ERL>0. as of today its not used in open-iscsi
> initiator. well, anyway. I guess right fix would be:
>
> for open-iscsi: remove checking

u might have interest to add this as a conditional check. so u can have
it when u need but leave it off by default.

>
> for IET: make sure LUN in R2T matching original SCSI Command request.
>

en i think this solution is acceptable. :)

[FUJITA Tomonori]

From: Ming Zhang <mi...@ele.uri.edu>
Subject: Re: [Ips] LUN or reserved in R2T?
Date: Mon, 07 Mar 2005 08:56:32 -0500

> > for IET: make sure LUN in R2T matching original SCSI Command request.
> >
> en i think this solution is acceptable. :)

It's done at r999. And as I said in the IET mail list, I also fixed
the high CPU utilization issue. So please try it.

If r999 is OK, I'll release it as 0.4.6.

[Ming Zhang]

On Sun, 2005-03-06 at 23:54, Julian Satran wrote:
> The answers given up to know should have clarified the issue. The A
> bit is mentioned only because the positive SACK needs the same two
> fields (TTT & LUN).
> THe reason all outgoing solicited PDUs have those fields are:
> * TTT a convenience label to help the target identify an
> internal control structure related to the incoming PDU
> * LUN to enable the target to define TTT per LU (in case the
> work is done by different control entities at the target)
>
>
> Obviously those value have to be consistent with those used by the
> initiator - and referred to by ITT.
> ITT is the primary "identifier" of a task.
>
> As I indicated earlier - you should do it correctly to ensure
> interoperability but you are not mandated to check what others do (ass
> long as you can live with it).
thanks. i think this is a very good summary on this question. we will
modify (in fact, we are modifying) base on this.

thanks again.


>
> Certain compliance test suites will certainly indicate that you are
> not compliant if you do not set consistent values in those fields.
>
> Julo
>
>
> Ming Zhang <mi...@ele.uri.edu>
> Sent by: ips-b...@ietf.org
>
> 06/03/2005 21:08
> Please respond to
> mi...@ele.uri.edu
> To
> "Nicholas A.
> Bellinger"
> <ni...@pyxtechnologies.com>
> cc
> i...@ietf.org,
> open-iscsi
> <open-...@googlegroups.com>, Eddy Quicksall <eddy_quicksall...@comcast.net>

> Subject
> Re: [Ips] LUN or
> reserved in R2T?
>
>
>
>

> _______________________________________________
> Ips mailing list
> I...@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips