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

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

org:StorageTek;Minnesota Research and Development Center
email;internet:dap at network.com
title:Principal Engineer
fn:David A. Peterson


More information about the T10 mailing list