Subject: RE: iSCSI UNH Plugfest

From: "Elliott, Robert" <[email-masked]>
Date: Thu, 14 Feb 2002 20:57:41 -0600

Although those bits are often reserved, some commands use them (e.g.
SEND DIAGNOSTIC).  It's not safe to guess that they contain a 3 bit LUN
value.

The iSCSI initiator driver should clean up the CDB as needed (your first
suggestion) and keep the wire protocol clean.  If it's in an OS
generating old CDBs, it knows that and is best suited to fix them.
Don't burden the iSCSI targets with any of this.

The UNH test suite should check for compliance for this and other basic
SCSI functionality, like:
* initiators can send 16 byte CDBs
* initiators can send 8-byte LUNs
  * but honor the LUN structure in SAM-2
* logical units implement all mandatory commands:
  * INQUIRY
  * REQUEST SENSE
  * REPORT LUNS
  * TEST UNIT READY
* additional mandatory commands for block or stream devices
* initiators handle all status codes, especially:
  * CHECK CONDITION
  * BUSY
  * TASK SET FULL (using recommended retry algorithm from SAM-2)
  * RESERVATION CONFLICT
* logical units implement mandatory task management functions:
  * ABORT TASK
  * ABORT TASK SET
  * CLEAR TASK SET
  * LOGICAL UNIT RESET
* logical units implement VPD pages 80h and 83h
  * 80h unit serial number
  * 83h NAA type IEEE Registered or IEEE Registered Extended
* initiators don't send TARGET RESETs
* initiators check the page code in the sense data
* initiators use logical unit VPD data to identify logical units, not
the dynamic fabric/bus address of the target

---
Rob Elliott, Compaq Server Storage
[email-masked]

> -----Original Message-----
> From: Robert D. Russell [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 4:12 PM
> To: Julian Satran
> Cc: [email-masked]
> Subject: Re: UNH Plugfest
> 
> 
> Julian:
> 
> The last several days at the UNH plugfest have uncovered no major
> issues relating to the standard.
> 
> One thing that was observed was that a number of implementations are
> dealing with SCSI-2 systems, because most of the world (i.e., Windows)
> is still based on SCSI-2.  The iSCSI standard clearly references the
> SCSI-3 specifications.  However, perhaps we should consider how iSCSI
> could be used with SCSI-2.
>
> In particular, there is the issue of LUNs.  Some implementers are
> expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order
> bits of byte 1 in the CDB, and are not setting/using the LUN field
> in the iSCSI PDU.  This is clearly wrong, although if both target and
> initiator do it, then they interoperate with each other but not with
> standard-conformant implementations.
> 
> Of course, there may be (and probably are) additional issues (besides
> the LUN issue) that may arise.  However, it still might be useful to
> warn implementers that this is an issue, and perhaps to suggest a
> "conversion rule" that would allow SCSI-2 to interoperate with iSCSI.
> 
> One possibility for such a rule follows:
> 
> If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN,
> it should extract the LUN from the 3 high-order bits of CDB byte 1
> and send that in the iSCSI LUN field (unless, of course, it has some
> other means of obtaining the LUN value independent of the 
> CDB, in which
> case it should send that value in the iSCSI LUN field).
> 
> If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if
> the iSCSI LUN field is 0 it should extract the LUN value from the
> 3 high-order bits of CDB byte 1 (which in the SCSI-3 case 
> should always
> be 0 anyway) and use that as the LUN value;
> if the iSCSI LUN field is not 0 then it should use that as 
> the LUN value.
> 
> At first glance this rule seems to allow an initiator and/or a target
> to interoperate with both SCSI-2 and SCSI-3 systems.

---

From: "ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 15 Feb 2002 09:17:00 -0800

> From: Elliott, Robert [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 6:58 PM
> To: [email-masked]
> Subject: RE: iSCSI UNH Plugfest
> 
> 

Correct.

> Don't burden the iSCSI targets with any of this.

I second that!
 
> The UNH test suite should check for compliance for this and 
[snip]
>   * 83h NAA type IEEE Registered or IEEE Registered Extended

Yes, please do. The world will be a better place for storage administrators,
your customers will love you.

> * initiators don't send TARGET RESETs

Yes, please do. Disruptive in multi-initiator environments (which is mostly
the domain of FC & iSCSI).

> the dynamic fabric/bus address of the target

YES, please do. Again your customers will love you!

-Shawn

---

From: Eddy Quicksall <[email-masked]>
Date: Fri, 22 Feb 2002 18:15:18 -0500

> Don't burden the iSCSI targets with any of this.

I don't agree that the iSCSI initiator should touch the CDB. This is a ULP
issue and the issuer of the CDB should use or not use the bits as desired.

Maybe that is what you meant. 

Eddy

-----Original Message-----
From: ERICKSON,SHAWN (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Friday, February 15, 2002 12:17 PM
To: 'Elliott, Robert'; [email-masked]
Subject: RE: iSCSI UNH Plugfest

Correct.

I second that!

[snip]

-Shawn

---

From: [email-masked]
Date: Mon, 25 Feb 2002 13:20:16 -0500

> issue and the issuer of the CDB should use or not use the 

This seems to be mostly about where to locate the code that sets the
iSCSI LUN when a SCSI-2 stack sits on top of iSCSI.  Setting the iSCSI
LUN correctly is a MUST, otherwise SCSI task management will misbehave.

If one wants to split hairs, SCSI-2 code should figure out the LUN and
pass it to iSCSI code that puts it in the correct place in the iSCSI PDU.
In practice, I'm not sure this distinction is important, as I can easily
imagine this sort of design boundary being optimized out in various ways
by implementations.

On the more generic issue of SCSI-2 over iSCSI, if someone (or a set
of someones) wanted to write up an informational draft on the set of
issues that arise in doing this, that would be welcome.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------