FW: 00-140r0 - Bug in SAM-2 Task Identifier Definition
ralphoweber at CompuServe.COM
Tue Mar 21 20:12:32 PST 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
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.
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.
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
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.
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.
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.
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
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.
Second, both the Task Identifier and Task
Address object definitions should use Port
Identifiers, instead of Target Identifier
and Initiator Identifier, respectively.
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.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10