FCP-2: Command reference per LUN????

David A. Peterson dap at storage.network.com
Mon Jun 26 09:05:54 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "David A. Peterson" <dap at storage.network.com>
*
This is a multi-part message in MIME format.
--------------45901F4346102F6A5E6C3294
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The issue of whether CRN is target or lun based was discussed quite a
while back and I argued the same points as Matt below but lost the
battle. Given that, I persued the concept of adding the CRN to the SAM-2
model with no luck (at the time).

The main (only?) reason CRN was made lun based was that the disk drive
target/lun did not want to see the CRN in the FCP command payload. Also,
still believe the use of a continuously increasing OX_ID can acheive the
same result as a target based CRN (i.e it's unfortunate we need to have
the concept of CRN is the first place).

Matt Wakeley wrote:
> 
> *
> * From the fc reflector, posted by:
> * Matt Wakeley <matt_wakeley at agilent.com>
> *
> In FCP-2, it says in section 4.3:
> 
> "Precise delivery of SCSI commands uses the COMMAND REFERENCE NUMBER (CRN) in
> the FCP_CMND IU. For each device server having the EPDC bit set to one, the
> application client places a monotonically increasing one byte integer in the
> CRN field for each command that is transmitted that also requires precise
> delivery."
> 
> Where "device server" is defined in 3.1.15 as "An object within the logical
> unit which executes SCSI tasks and enforces the rules for task management."
> 
> And in 9.1.1.2 it says "The COMMAND REFERENCE NUMBER (CRN) is provided by the
> initiator to assist in performing precise delivery checking for FCP commands.
> If precise delivery is enabled, a nonzero value of CRN shall be treated as a
> command reference number in determining the receipt and ordering of commands
> from a particular initiator to the particular logical unit as described in
> 4.3."
> 
> All this says that the CRN is maintained on a per LU basis.  This will require
> that FCP maintain a "table" of CRNs for every LU in every SCSI target that it
> is communicating with.  Remember, SCSI does not have any concept of CRN.
> 
> I thought the understanding during the discussions of this, that that CRN was
> based on a per TARGET, *not* LU behind the target.
> 
> In other words, the SCSI driver passes commands to the FCP layer to be
> delivered across fibre channel to the target.  SCSI does not have a concept of
> CRN, so, no CRN is passed to the FCP driver.  FCP has to guarantee that these
> commands are delivered back to SCSI at the target in the same order that the
> SCSI driver passed the commands to FCP (as per SAM-2).
> 
> So, what these words are requiring is that SCSI will have to be modified to
> track this CRN on a per LU basis.  FCP-2 does not have the knowledge of
> information of what's stored in LU control pages (the EPDC bit).  If FCP is
> required to have knowledge of all the LUs behind all the targets it is
> communicating to, this is violating the boundary between what is FCP and what
> is SCSI.
> 
> Also, if FCP is required to keep track of all the possible CRNs for each LU
> behind each target that it is communicating with, that is a lot of state to
> keep around in chips and/or firmware and/or fibre channel drivers.
> 
> FCP(-2) is a "mapping" of SCSI to be delivered across Fibre Channel.  That is,
> it is a Transport across FC. It should not have to have knowledge about the
> internals of SCSI (details about mode pages, number of LUs behind a target,
> etc).
> 
> In SAM-2, the SCSI Command Model is defined as:
> 
> Service response =Execute Command (Task Address, CDB, [Task Attribute],
> [Data-Out Buffer], [Command Byte Count], [Autosense Request] || [Data-In
> Buffer], [Sense Data], Status)
> 
> No where is there a CRN. Is FCP-2 placing a new requirement on SCSI (SAM-2) to
> include CRN's in it's command model?
> 
> The text in FCP-2 needs to be changed to eliminate this notion of CRNs per
> LU.  The CRN was meant to be on a per Target basis.
> 
> -Matt Wakeley
> Agilent Technologies


--------------45901F4346102F6A5E6C3294
Content-Type: text/x-vcard; charset=us-ascii; name="dap.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: ATTACHMENT; filename="dap.vcf"
Content-Description: Card for David A. Peterson

begin:vcard 
n:Peterson;David
tel;cell:612-251-6229
tel;work:763-391-1008
x-mozilla-html:FALSE
org:StorageTek;Minnesota Research and Development Center
adr:;;;;;;
version:2.1
email;internet:dap at network.com
title:Principal Engineer
fn:David A. Peterson
end:vcard

--------------45901F4346102F6A5E6C3294--




More information about the T10 mailing list