RE: iSCSI: items discussed at WG meeting

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

> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, March 20, 2002 6:20 PM
> Subject: Re: iSCSI: items discussed at WG meeting
> 
> Dave Peterson wrote:
> > 8. CRN Processing and behavior: spec currently references 
> > SAM-2 for CRN.
> > 
> > Per SAM-2:
> > Command Reference Number (CRN):
> > When this argument is used, all sequential commands of an 
> > I_T_L nexus shall include a CRN argument that is incremented 
> > by one. The initial, wrap, and reset CRN values shall be one. 
> > The CRN value zero shall be reserved for use
> > as defined by the SCSI protocol. It is not an error for the 
> > application client to provide this argument when CRN is not 
> > supported by the SCSI protocol or logical unit.
> > 
> > More text specifying the behavior of CRN in the iSCSI realm 
> > is needed. In addition, a method to determine if CRN is being 
> > used (or not) is missing.
> 
> We went through this discussion several months ago in another ips
> thread. CRN really belongs to the SCSI ULP and any mechanism 
> to check if the device server supports CRN should be in a SCSI ULP 
> mode page (like the Control Mode Page).

I agree this bit fits better there, but to date there is no such 
bit in the Control mode page and no proposals on the T10 CAP 
agenda to add one.

In the only protocol supporting this feature (FCP-2), the bit is
in the Protocol-Specific Logical Unit Control mode page.  If a 
bit is added to the Control mode page for iSCSI and future
protocols, it makes FCP-2 targets non-compliant. I'm not sure 
that there are any implementations of CRN yet that would care. 

> As far as iscsi is concerned, both the iscsi initiator and target
> implementations MUST support CRN, since it is defined in iscsi
> command pdu. 
>
> Why is such a method required at the SCSI LLP layer ?

iSCSI defers too much to SAM-2:
"9.3.2 CRN
 SCSI command reference number - if present in the SCSI 
 execute command arguments (according to [SAM2])."

To depend on the CRN in its Execute Command() remote
procedure call, an application needs to know:
a) the initiator port supports sending CRN;
b) if there are any protocol bridges/gateways in the service 
delivery subsystem, all the protocols between the initiator
port and target port support CRN;
c) the target port supports CRN; and
d) the logical unit supports and honors CRN.

Presumably the initiator's API will reject the RPC
if a) is not honored.  

Applications currently detect and set c) and d) with 
the Protocol-Specific Logical Unit Control mode page.
Moving to the Control mode page would be a change
but is certainly possible.  iSCSI needs to provide
this information/control somehow.

For b), bridges need to be able to report that CRN is not 
available over iSCSI because they're bridging to a protocol
that doesn't support it.

A text key would work pretty well, but this capability 
is logical unit based, not target-based.  This leaves 
intercepting mode page accesses and modifying the mode 
page data.

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com