FCP-2: Reasons why CRN must be target based (not lun based)

[Matt Wakeley]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Matt Wakeley" <matt_wakeley at agilent.com>
*
In the T11.3/T10 meeting on 7/10, there was a (long) discussion on whether the
CRN (command reference number - better defined as the CON, command order
number) should be based on a per LU basis or a target basis.  I argued that it
should be on a per target basis because FCP-2 really defines the behavior of
the Fibre Channel SCSI Delivery Subsystem.  The SDP (SCSI Delivery Port) on
the initiator and the SDP on the target work together to guarantee that the
commands submitted to the initiator SDP are delivered from the target SDP in
the same order they were submitted to the initiator SDP.

CRN on a target basis requires that the initiator SDP maintain a CRN counter
on a per target basis that is incremented when any command is delivered to the
target.  The SDP already has data structures on a per target basis anyway to
store items such as the Node ID, and login information.  So it is not much
extra overhead for the SDP to maintain this CRN counter on a per target basis.

CRN on a LU basis requires that some entity maintain the CRN on a LU basis per
target.  Now, (in a properly layered model) the SDP does not know anything
about how many LUs there are in a target, and how those LUs are assigned
numbers (LUNs).  The LU information is gathered and maintained by the upper
level SCSI (class) driver and/or the application. This means that if the
initiator SDP is to maintain the CRNs on a per LU basis, it must maintain 2^64
CRNs per target (since the LUN field is 64 bits). (I reject the arguments that
the FCP-2 SDP duplicate the discover LUNs functions that are already performed
by the upper layers - that's why I said "properly layered".)

The argument was that the SDP does not have to maintain this large table
because the SCSI (class) driver and/or application will pass the value to the
SDP as part of the parameters of CDB.

I pointed out that currently in NT there is no way for the application to pass
this CRN through the MS SCSI class driver, and the MS SCSI class driver
certainly does not maintain a CRN.

The argument against this was that there currently are not any "queuing"
applications that run on NT that require command ordering, so who cares about
CRN in the NT environment. And that when/if there are, the applications will
be written to maintain the CRN, and MS will modify the SCSI class driver to
enable passing the CRN to the SDP.

Well, my response to that is that suppose someone did write a "queuing"
application on NT that requires command ordering.  If the application is run
on a system using a SCSI parallel bus, the application doesn't need to
maintain a CRN, since "errors don't occur on the SCSI parallel bus" and
commands will always be delivered in order.  If the application is run on a
system using the "SCSI over VI" transport, the application doesn't need to
maintain a CRN because the VI environment will deliver messages in order.  If
the application is run on a system using the proposed "SCSI over IP"
transport, the application doesn't need to maintain a CRN because that
transport will also deliver commands in the order they are passed down the
stack.

*BUT* if this application is run on a system using Fibre Channel, all of a
sudden the application is required to maintain a CRN value on a per LU basis,
because FCP at the SDP layer is unable to deliver commands from the SDP layer
to the LUs in the order they were passed to the SDP layer on the initiator
side.  This certainly doesn't make applications portable to Fibre Channel.
Also, since FCP-2 is now mandating that the LU is to maintain this ordering,
it forces a change to SAM-2 to define to the command reference number as a
parameter to the LU.

Therefore, I still maintain my argument that FCP-2 *MUST* implement the CRN on
a per target basis so that FCP-2 (which implements the SAM-2 SDP) can deliver
commands up from the target SDP to the LUs in the same order they were
submitted down to the initiator SDP.

Matt Wakeley
Agilent Technologies

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org