FW: 00-140r0 - Bug in SAM-2 Task Identifier Definition

[George Ericson]

* From the T10 Reflector (t10 at t10.org), posted by:
* "George Ericson" <gericson at mindspring.com>
*
Ralph,
I hope we are converging.  Comments inline.
George

|-----Original Message-----
|From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Ralph
|Weber
|Sent: Tuesday, March 21, 2000 11:13 PM
|To: T10, Reflector
|Cc: Ericson, George
|Subject: Re: FW: 00-140r0 - Bug in SAM-2 Task Identifier Definition
|
|
|* From the T10 Reflector (t10 at t10.org), posted by:
|* Ralph Weber <ralphoweber at compuserve.com>
|*
|George,
|
|First, I must admit that the contention that the task
|manager is a LLP entity (or component of the service
|delivery subsystem) is the most illuminating concept
|to come out of this entire exercise.  If this view
|proves useful and a wider consensus can be gained
|supporting it, I think it should be represented in
|wording changes to SAM-2.  I hope you will agree that
|the current wording is, at best, vague on the subject.
--------------------------------------------------
GME: Agree.
--------------------------------------------------
|
|Next, I am fully aware of all or virtually all the
|SAM and SAM-2 quotes you presented, they are accurate
|and I will not repeat them here as doing so obscures
|the issues at hand.
|
|In mid 1994, several changes were introduced in SAM
|revision 15 with the intent of documenting dual port
|operation.  Among those changes was a task management
|function given several names including TARGET RESET
|OTHER PORT.  Protests were raised that the model
|should not restrict devices to just two ports.  Several
|members felt that the 'other port' concept and other
|details of the dual port model imposed unacceptable
|restrictions on the design of SCSI products.
|
|All this happened late in the SAM development cycle.
|The forwarding letter ballot had been processed and
|comments resolution was all but finished.  Rather than
|delay the first public review for SAM, X3T10 decided
|to remove discussion of dual port devices from SAM.
|
|The specific motion was:
|
|Bob Snively moved that Gary Stephens’ motion be amended
|to include instructing Charles to remove the dual port
|information added in revision 15 without prohibiting dual
|porting. Jim McGrath seconded the motion to amend. The
|motion to amend passed 22:4:0:31.
|
|For reference, the above text can be found in the minutes
|of X3T10 Plenary Meeting #5 held in Houston, TX, document
|X3T10/94-192r2, PDF page 9 (about the third paragraph from
|the bottom of the page).
|
|Looking at the exact words of the motion, I guess you
|could say that we are both right.  X3T10 did not
|completely strip dual porting from SAM.  However,
|substantial parts of the model for dual port (or
|multiple port) devices were removed from SAM, with
|the intention that SAM be mostly silent on the subject
|of multiple port devices and that final definition of
|the model be completed in SAM-2.
|
--------------------------------------------------
GME: It may have been the intention to be silent, but as I've demonstrated,
an unambiguous multi-port model is still present in SAM.
--------------------------------------------------
|Full definition of the SAM-2 multi-port model is the
|task currently being undertaken by the CAP Working
|Group.  One of the steps in that process was an
|attempt on my part to respond to a strongly stated
|belief that "each port is a unique SCSI Device."
|The SMU (SCSI Multi-port Unit) concept was created
|in an attempt to address that concern.
|
|As of this writing, the SMU concept is falling into
|some disfavor.  Arguments are being made (but not
|yet fully accepted) that a SCSI Device can contain
|multiple Targets and/or multiple Initiators each
|one of which has only one port.  For a time, it was
|suggested that Targets and Initiator be allowed to
|have multiple ports, but (in my opinion) the proponents
|of that idea have back off in the face of very strong
|opposition and the Herculean task of showing that
|every usage of Target in the current SAM-2, SPC-2,
|SBC, SSC, SCC, RBC, MMC-2, et. al. is appropriate
|in light of the definition.  (Note: many of the
|occurrences of Target in the command set documents
|date back to SCSI-2 and SCSI-2 defined only single
|port devices.)
--------------------------------------------------
GME: If one accepts the notion that Target ID is a synonym for Port ID in
current and past SCSI documents, then the task becomes something mere
mortals can handle.
--------------------------------------------------
|
|At the last working group meeting, the proponents of
|the 'SCSI Device with multiple Targets (Initiators)'
|idea committed to preparing a detailed proposal showing
|how the idea can be worded throughout SAM-2 (and
|possibly SPC-2).  This is not an insurmountable task
|because the term 'SCSI Device' was introduced by
|SCSI-3.  Presumably, that proposal will be on the
|table at the May meetings.
|
--------------------------------------------------
GME: Hopefully proposals for the May meeting will be published soon enough
to allow for thorough review prior to the meetings.  If there is a separate
mail list for CAP, I'd like to be added to it.
--------------------------------------------------
|On to some other topics from this thread.  You'll
|remind me if I miss something.
|
|I am not sanguine on the notion that Target can
|use Target Identifier to identify the port-source
|of a command.  I believe that introducing the
|Port Identifier object has value as part of the
|ongoing process to complete the model of multiple
|port devices left dangling in SAM.  Thus I believe
|that Port Identifier should not be equated to
|Target Identifier by the model.  In particular,
|the effects of two implementation issues on the
|model come to mind.
|
|First, Target Identifier generally is understood
|to be a bus ID in parallel SCSI and something like
|AL_PA in Fibre Channel.  In the instance where two
|(or more) ports are connected to different busses
|or loops, it is perfectly valid for all ports to
|end up with the same Target Identifier value.
|This suggests that a Target implementation must
|use something other than the Target Identifier
|value to distinguish the ports.
--------------------------------------------------
GME: Absolutely true:  There are two items that the Target implementation
may use to disambiquate paths.

One is the Initiator ID.  This is available at the port level in all
implementations.

This by itself is not sufficient for all LLPs since if each port is attached
to a different SCSI Interconnect Subsystem, (and therefore SCSI Domain),
then the Initiator IDs could also be equal.  (True in with SPI.  Not true
for FC, since AL_PAs are just aliases for port/node WWN pairs. Those WWN
pairs must be unique and that information is available at the LLP level.)

The other is via the internal use of target relative Bus and Target/Port
IDs.  In this context, there is no need for the target implementation to
export this information.  It is sufficient that when a command passes from a
port through a target to a device server, the external representation of the
path is translated into an internal representation of that path.

Note, this idea is derived from the documentation for Logical Unit and
Peripheral Device Address formats.  Although not clearly documented, the
only way that these address methods can work are if the Bus and Target IDs,
which are encoded into these formats, are specified relative to the target,
not the initiator.  (Draw some sample topologies and you'll quickly see what
I'm getting at.)
--------------------------------------------------
|
|Second, the model should be flexible enough to
|allow Target implementations appropriate latitude
|in their design.  If using a PCI bus address is
|the best way to identify ports in a target, then
|the model should be open to that implementation.
|I don't see how having the model specify Target
|Identifier as the object naming ports permits
|such an implementation.
--------------------------------------------------
GME: Are you talking from the initiator's point of view, or from the
target's?  I'll try to justify that using PCI bus address today is already
supported from three different points of view.

>From the Initiator, a Target ID is a 64 bit unsigned number.  As long as PCI
bus address doesn't exceed 64 bits I don't see any problem at all using it.
Implementation is an LLP detail.

>From the Target, (see above), this is an internal affair and again, I don't
see any existing prohibitions against using a PCI bus address.

The only case where there is trouble is with existing Logical Unit and
Peripheral Device Address formats.  The widest target address available
there is 8 bits.  The out is for the target to hide the use of the PCI bus
address behind the use the Device Dependent (used to be Virtual Device)
Address format.
--------------------------------------------------
|
|This leads me back to the 'bug' in the SAM-2
|definition of Task Identifier, which is the topic
|of 00-140r0 and apparently has gotten lost in
|all this discussion.  The 'bug' is that SAM-2
|includes the Target Identifier in the object
|definition for Task Identifier (which is the
|identifier a target uses to distinguish one
|task from another).  There are two problems
|with this.
|
|First, the Task Identifier object definition
|is not symmetric with the Task Address object
|definition (which is the identifier an initiator
|uses to distinguish one task from another).
|Specifically, the Task Address object definition
|does not include the Initiator Identifier object.
--------------------------------------------------
GME:  This is not a problem.  The initiator's Service Delivery Port is
required to translate a Task Address into to a Task Identifier.  This is
documented for Task Management Protocol, but not for the Command Protocol in
SAM-2:

See the Object Address Definition in 6.7.  Reproduced here:

"Object Address: A Task Address, Logical Unit Identifier or Target
Identifier supplied by the application client to identify the object to be
operated upon. The initiator's service delivery port will convert a Task
Address to a Task Identifier before forwarding the request to the target."

Note that Task Address is only used when sending commands from the Initiator
to a Target.  So regardless of whether at the Initiator or at the Target,
there is enough information to translate the Task Address internally to a
Task Identifier within the LLP.

I suggest that the SAM-2 Command Protocol documentation be updated to be
consistent with the Task Management Protocol documentation.

At the ULP level, Task Identifiers are only issued by the Device Server.
--------------------------------------------------
|
|Second, both the Task Identifier and Task
|Address object definitions should use Port
|Identifiers, instead of Target Identifier
|and Initiator Identifier, respectively.
--------------------------------------------------
GME:  As seen above, the LLP translates a Task Address to a Task Identifier
before delivery to a Device Server.  As shown in my last email response, the
Task Identifier is defined by SAM and SAM-2 to contain both an Initiator
Identifier and a Target Identifier.  This is necessary for a Device Server
to unambiguously identify a particular task to an Application Client.
--------------------------------------------------
|
|Finally, all of these issues affect the ongoing
|work on FCP-2, as FCP-2 intends to coordinate
|identifier definitions with SAM-2, or at least
|that is my understanding.
--------------------------------------------------
GME:  Everything I've said so far is consistent with FCP-2, SCP-2, and SAM-2
documentation.
--------------------------------------------------

Regards,
George

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