Re: [Fwd: iSCSI: items discussed at WG meeting]

["Julian Satran" <Julian_Satran@il.ibm.com>]

I agree.  It would also relieve us from having to maintain per-LU information in iSCSI (we have none today).

Julo

Santosh Rao <santoshr@cup.hp.com> Sent by: owner-ips@ece.cmu.edu 26-03-02 04:21 Please respond to Santosh Rao

To:        IPS Reflector <ips@ece.cmu.edu>         cc:                 Subject:        [Fwd: iSCSI: items discussed at WG meeting]

Rob,

FCP-2's EPDC bit really ought to be considered a SCSI LLP peer to peer
mechanism to check and enable CRN support in FCP_CMD, since FCP did not
support CRN in the FCP_CMD IU.

There should be a seperate SCSI ULP peer to peer mechanism which
involves the application client testing and enabling CRN support in the
device servers being accessed.

Only legacy scsi transports should require the former, due to early
versions of such legacy scsi transports not having supported CRN.

Future SCSI transports (iscsi, srp, etc) ought to only need the later
SCSI ULP peer to peer mechanism to test and enable CRN in the peer SCSI
ULPs.

It would be a better preservation of layering to require a change in 
CAP which provides an enable_crn bit in the control mode page, than to
further propagate the violation of layering that FCP-2 seems to have
created with its EPDC bit testing both the SCSI LLP and ULP
capabilities.

Regards,
Santosh




"Elliott, Robert" wrote:
> 
> > -----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

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################