Subject: [Ips] LUN or reserved in R2T?

From: Ming Zhang <[email-masked]>
Date: Sat, 05 Mar 2005 11:51:07 -0500

In R2T, shall the LUN field have actual LUN value or can be reserved?

I knew this is asked before. but the archival i can find is 
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09192.html, which is in
2002, pretty old. And there is no formal description on this field in
10.8.

Thanks.

Ming

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Eddy Quicksall" <[email-masked]>
Date: Sat, 5 Mar 2005 18:50:44 -0500

It is up to the target:

The Target Transfer Tag and LUN are copied in

   the outgoing data PDUs and are only used by the target.

Eddy

---

From: "Eddy Quicksall" <[email-masked]>
Date: Sat, 5 Mar 2005 19:11:15 -0500

I see the confusion because the LUN in the R2T is only used by the target so 
that says the initiator must only copy it and not use it. But the data out 
which was solicited by the R2T must have a valid LUN.

So, the best thing is to make sure the LUN is valid when you send the R2T.

Eddy

---

From: Ming Zhang <[email-masked]>
Date: Sat, 05 Mar 2005 22:33:35 -0500

> So, the best thing is to make sure the LUN is valid when you send the R2T.
yes, this is the best thing.

but can we safely say this?

1) initiator should not check the validity of LUN field and should
simply copy it to data out packet
2) if target wants to check the validity of lun field in data out
packet, then target should supply a valid lun field in r2t packet?

ming

---

From: Ming Zhang <[email-masked]>
Date: Sat, 05 Mar 2005 22:35:32 -0500

>    the outgoing data PDUs and are only used by the target.
see my another email, if this is only used by the target, then initiator
should never check this?

ming

---

From: "Nicholas A. Bellinger" <[email-masked]>
Date: Sun, 06 Mar 2005 00:09:48 -0800

Hi Ming!!

> see my another email, if this is only used by the target, then initiator

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.

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.

Take care,

-- 
Nicholas A. Bellinger <[email-masked]>
Chief Architect, PyX Technologies, Inc.

-- 
Nicholas A. Bellinger <[email-masked]>

---

From: Ming Zhang <[email-masked]>
Date: Sun, 06 Mar 2005 11:14:02 -0500

> > see my another email, if this is only used by the target, then initiator
Thank you, Nicholas,

> 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?

> with these initiator implementations.
This is to say that you allow other guys to do something not so good. :)

But the question is, what does the rfc say? and which one strictly
follows the standard?

I put question completely on the table, we
(http://iscsitarget.sourceforge.net/) leave that field reserved in R2T,
while open-iscsi(http://www.open-iscsi.org/) checks this field to make
sure it is LUN. so...

ming

---

From: "Nicholas A. Bellinger" <[email-masked]>
Date: Sun, 06 Mar 2005 12:34:32 -0800

> 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.

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.

> 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

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.

---

From: Ming Zhang <[email-masked]>
Date: Sun, 06 Mar 2005 22:08:00 -0500

> original SCSI command PDU, and not what the target may or may not be
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.

> subsequent DataOUT PDUs fullfilling the R2T.
i admit that this is really conservative. :P

thanks.

ming

---

From: Julian Satran <[email-masked]>
Date: Sun, 6 Mar 2005 22:54:11 -0600

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).

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 <[email-masked]> 
Sent by: [email-masked]
06/03/2005 21:08
Please respond to
[email-masked]

To
"Nicholas A. Bellinger" <[email-masked]>
cc
[email-masked], open-iscsi <[email-masked]>, Eddy Quicksall 
<[email-masked]>
Subject
Re: [Ips] LUN or reserved in R2T?

as 10.7.4

thanks.

ming

---

From: Julian Satran <[email-masked]>
Date: Sun, 6 Mar 2005 22:54:07 -0600

06/03/2005 14:34

To
Ming Zhang <[email-masked]>
cc
[email-masked], Eddy Quicksall <[email-masked]>
Subject
Re: [Ips] LUN or reserved in R2T?

---

From: Ming Zhang <[email-masked]>
Date: Mon, 07 Mar 2005 09:43:16 -0500

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).
>       * 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)
> 
> 
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
> 
> 
> "Nicholas A.
> Bellinger"
> <[email-masked]>
>                cc
> [email-masked],
> open-iscsi
> <[email-masked]>, Eddy Quicksall <[email-masked]>
>           Subject
> Re: [Ips] LUN or
> reserved in R2T?
> 
> 
> 
>