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

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

Don't assume that every new SCSI protocol will support CRN - 
SRP does not, for one.  Logical units on protocols that
do not will not support the Control mode page bit (leaving
it 0).  

Are you going to write a proposal for CAP to add a bit to 
the Control mode page?  

This two-level approach still leaves a hole for current 
FCP-2 applications/targets, which don't yet know about the
Control mode page bit:

LU Control bit on, Control bit on => CRN in use
LU Control bit on, Control bit off => no CRN
  existing targets don't implement the Control mode page bit;
  existing applications assume the LU Control page suffices
  to enable CRN. 

LU Control bit off, Control bit off => no CRN
LU Control bit off, Control bit on => illegal

While iSCSI applications/targets will have a simpler matrix:
Control bit on => CRN
Control bit off => no CRN

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


> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Monday, March 25, 2002 8:21 PM
> To: IPS Reflector
> 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
> ##################################
>