RE: iSCSI UNH Plugfest

["Elliott, Robert" <Robert.Elliott@compaq.com>]

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
Robert.Elliott@compaq.com


> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
> Sent: Thursday, February 14, 2002 4:12 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> 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.