CRN

Douglas Hagerman Douglas.Hagerman at digital.com
Mon Jun 29 06:56:11 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Douglas Hagerman <Douglas.Hagerman at digital.com>
*
Hi Charles.

I think your point gets to the crux of this whole discussion. The goal
at the Fibre Channel level is simply to get things to the far end of the
interconnect in order. AFTER THAT, there are certain things that can be
done to control the SCSI device, such as target reset, etc.

	-----Original Message-----
	From:	Binford, Charles [SMTP:charles.binford at symbios.com]
	Sent:	Thursday, June 25, 1998 6:38 PM
	To:	FC at nsco.network.com
	Cc:	t10 at symbios.com
	Subject:	RE: CRN

	> And the answer: 
	> Assuming an in-order environment retransmit the required
	> command/CRN(s).
		[cb]  I don't get it.  At this point I'm not wanting to
	retransmit the command, I'm wanting to abort a set of IOs or
tell the
	target to reset himself because I think he is confused.   If
part of the
	target's confusion deals with managing the CRN number and the
task
	management function has to have a "valid" CRN to be accepted
then it
	seems I (the host) am stuck with a guessing game.  Not having a
CRN on
	the task management funcitons seems to simplify things.

These functions must be kept separate. For example, it was argued that
the reset function should put the device back to its power on state.
This means, of course, that it would need to do a LIP since that's part
of the power-on processing.

I don't think this is the right way to look at it. There are two things
going on here: At the lower level there's Fibre Channel and at the
higher level there's SCSI. There are a bunch of SCSI device management
or task management functions that are entirely related to the SCSI
device world, and then there is a completely separate set of FC
management functions.

The CRN is in the FC level (I keep wanting to say layer--why the heck
wasn't this a layered protocol from the get-go?) and is part of the
functionality that gets info to the far end. If something goes wrong at
this level it's the same case as if some other FC function goes wrong.

For example, in a parallel SCSI system if the REQ/ACK count got messed
up, one might clean up the problem by issuing a bus reset. However,
moving that to the Fibre Channel case, if for some reason the handling
of sequence initiative--which is clearly a purely Fibre Channel
function--were to get confused, the way to solve it is clearly NOT to do
a SCSI reset.

We need to be very careful about not mixing these layers. If it's a SCSI
layer issue (i.e. if it's in SAM) then it should be controlled by SCSI
layer functions, and if it's a Fibre Channel layer issue (i.e. if it's
in FCP or FC-xx) then it should be controlled by Fibre Channel layer
functions. CRN is, in my view, clearly an add-on to Fibre Channel to
allow exchanges to be ordered by the recipient.

Doug.

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





More information about the T10 mailing list