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

[Santosh Rao <santoshr@cup.hp.com>]

"Elliott, Robert" wrote:
> 
> Don't assume that every new SCSI protocol will support CRN -
> SRP does not, for one. 

Rob,

From a reading of SAM-2, it appears that the "Send SCSI Command" and
"SCSI Command Received" APIs (Section 5.4.2) define the CRN as one of
the arguments, which seems to imply that scsi transports should be
capable of transporting this argument, if the application client decides
to use it. (at least the newer scsi transports.)

Are you saying that this is not the case ? What is the basis for SRP not
supporting CRN ? 
What are the guidelines that determine whether a scsi transport should
support CRN or not ? 

If the CRN is not required to be supported by all scsi transports, is
there a reason that iscsi needs to support this ?

Regards,
Santosh



> 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
> > ##################################
> >

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