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

Mon Mar 20 05:09:00 PST 2000

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ericson, George" <gericson at clariion.com>
*
Ralph,
Comments inline.  In some cases, we are reading the SAM documents
differently.  To avoid searching through various revisions of SAM.  I've
included the text of my citations inline.

George
ralphoweber at csi.com
***********Need to fix ULP Target Reset arguments*****************

|-----Original Message-----
|From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Ralph
|Weber
|Sent: Sunday, March 05, 2000 8:36 AM
|To: 'T10, Reflector'
|Cc: GEricson at ieee.org
|Subject: Re: 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,
|
|} The Task Identifier is consumed at the Device Server,
|} which is an LU entity, not a target entity.  An LU may
|} be attached to an initiator via one or more targets/ports.
|} The Target ID is intended to identify that entity.
|
|The description of the problem is correct.  However, its
|use as a justification for the definition of the Task
|Identifier object is on very thin ice with respect to
|SAM (ANSI X3.270:1996).

GME: In SAM, the Task Identifier is defined as follows:

Logical Unit Identifier = Target Identifier + Logical Unit Number
Untagged Task Identifier = Initiator Identifier + Logical Unit Identifier
Tagged Task Identifier   = Initiator Identifier + Logical Unit Identifier +
Tag
Task Identifier = [ Untagged Task Identifier | Tagged Task Identifier ]

GME: Rewriting this:

Task Identifier = Initiator Identifier + Target Identifier + Logical Unit
Number + 0(Tag}1

GME: So, SAM defines a Target Identifier as an integral part of each Task
Identifer.

This is distinction is key in the following:

3.1.41 linked command: One in a series of SCSI commands executed by a single
task, which collectively make up a discrete I/O operation. In such a series,
each command has the same task identifier, and all, except the last, have
the link bit in the CDB control byte set to one.

A task identifier that is in use shall be unique as seen by the initiator
originating the command and the target to which the command was addressed.
(A task identifier is in use over the interval bounded by the events
specified i n 5.4). A task identifier is unique if one or more of its
components is unique within the scope specified above. By implication,
therefore, an initiator shall not cause the creation of more than one
untagged task having identical values for the target and logical unit
identifiers. Conversely, an initiator may create more than one task with the
same tag value, provided at least one of the remaining identifier components
is unique.

SCSI Command Received (Task Identifier, [Task Attribute], CDB, [Autosense
Request] ||)
Send Command Complete (Task Identifier, [Sense Data ], Status, Service
Response ||)
Send Data-In (Task Identifier, Device Server Buffer , Application Client
Buffer Offset, Request Byte Count||)
Data Delivered (Task Identifier ||)
Receive Data-Out (Task Identifier, Application Client Buffer Offset, Request
Byte Count,
Device Server Buffer ||)
Data-Out Received (Task Identifier||)

GME: Clearly, eliminating or modifying the Target Identifier portion of a
Task Identifier affects the fundamental operations on which the SCSI
protocol is built.

| SAM does not describe a model
|for multi-port devices.
|

It most certainly does.

The following are from SAM.

3.1.54 port: Synonymous with "service delivery port".

3.1.74 SCSI device identifier: An address by which an SCSI device is
referenced within a domain.

3.1.81 service delivery port: a device-resident interface used by the
application client, device server or task manager to enter and retrieve
requests and responses from the service delivery subsystem. Synonymous with
"port".

SDP: service delivery port.

Service Delivery Port: Device-resident component of the service delivery
subsystem (see object
definition 3). This object may contain hardware and software that implements
the protocols and interface to the interconnect subsystem.

Object Definition 3: SCSI Device
SCSI Device = [Initiator | Target | Target + Initiator] + 1{Service Delivery
Port}

GME: This is translated as a SCSI Device has one or more Service Delivery
Ports and an Initiator, a Target, or both.

Object Definition 5: Target
Target = 0{Logical Unit} + Logical Unit 0 + 1{Target Identifier} + Task
Manager
Target Identifier = bit<64>  -- [0|...|2**64 -1]

Object Descriptions:
Target Identifier: 64 bits identifying the target device.
As implied by object definition 5 above, a target device may respond to more
than one target identifier. Each target identifier shall be unique within
the
scope of the domain. The set of identifiers by which a target device is
referenced shall be the same for every initiator in the domain.

GME: Also implied is that the Target Identifier identifies a particular
Service Delivery Port.

The task manager controls the execution of one or more tasks by servicing
the task management functions specified in clause 6. Its external address is
equal to the target identifier. As specified in object definition 5,there is
one task manager per target device.

GME: Implication of above is that a task manager may have more than one
external address.

Initiator Identifier: Protocol-specific identifier of the initiator from
which the command originated (see 4.7.1).

GME: Clearly, SAM intends SCSI Target and Initiator Identifiers to both be
SCSI Device Identifiers.  SAM defines SCSI Device Identifiers to be unique
within a SCSI Domain.  The SCSI Domain is concerned with a single
interconnect system that has 2 or more Service Delivery Ports.  These must
be uniquely identifiable within the Domain.  The only conclusion reachable
is that SAM intends the Device Identifiers to name the Service Delivery
Ports.
This view is further supported in earlier versions of SAM-2, which make
statements like: "As discussed in the SCSI Device model (see 4.7), an SCSI
Device may have multiple Service Delivery Ports, each with its own Initiator
Identifier."  Or: "As discussed in the SCSI Device model (see 4.7), an SCSI
Device may have multiple Service Delivery Ports, each with its own Target
Identifier."

GME: Later versions of SAM-2 (starting with revision 9) removed this
wording.   Explanation given in revision history is: "It was widely felt
that 4.4 through 4.7 failed to convey the very important idea that each port
is a unique SCSI device."  I am certainly not in agreement with that
removal.  In fact, it clearly fundamentally changes the architecture from
that defined in SAM.

|In SAM-2, the problem described above is addressed by
|the addition of a Port Identifier object (see 4.9.2
|and 4.9.3 on PDF page 49 in sam2r12.pdf, and 4.10.2
|on PDF page 51).
|
|The SAM-2 model for multi-port devices is still under
|development.  However, I believe that having a separately
|named Port Identifier object will survive the development
|process.

GME: Remember that in SAM through SAM-2.8, the Target Identifier was equal
to the Port Identifier.

|
|The Port Identifier need not be identical to the Target
|Identifier, which allows implementations that use other
|identifiers such as PCI bus address to distinguish ports.
|Furthermore, a dual ported target could be configured
|on to separate SCSI Busses and be given the same
|Target Identifier on each port/bus.  Therefore, Target
|Identifier is not guaranteed to be a unique identifier
|for the port.

GME:  SAM,SAM-2.8, and SAM-2.12 all require that the Port Identifier be part
of the task address. Note that in SAM through SAM-2.8 this was explicit as
the Target Identifier was equal to the Port Identifier.  In SAM-2.12 the
result is the same, but a little more complicated.  In a non-SMU device, the
Target Identifier is still equal to the Port Identifier.  In an SMU device,
a new Port Identifier is concatenated to the Target Identifier.  Note that
Port Identifiers must be unique within a SCSI Domain.  Therefore, the Target
Identifier is superfluous and the new Port Identifier would be sufficient.
The net of this is that SAM-2.12 could be simplified back to SAM-2.8 with no
lose in functionality.

|
|} Two tasks delivered by the same initiator to the same
|} LU but through different target/ports are considered
|} to be separate and distinct.
|
|This statement is true.  However, it leaves the incorrect
|impression that the target might somehow be able to
|recognized that the two tasks are from the "same
|initiator."

GME: I wouldn't have lept to that conclusion.  In fact, it should be clear
|from SAM and SAM-2 that there is no guarentee that two ports are connected
to the same service delivery system.  Therefore, no guarentee that they
belong to the same SCSI Domain. Therefore, even if the Initiator Identifiers
are equal, there is no guarentee that they identify the same SCSI Domain.

GME: Agreed.

|
|} You did not describe the FCP-2 problem clearly.
|} Please be more explicit?
|
|See FCP-2 Letter Ballot Results (T10/00-005r0) ENDL
|comment 40 (PDF page 13).

GME: From your reference, (included ENDL-39 since it is cited in ENDL-40):

"ENDL-39 Clause A.1 Table A.1, equivalence to task identifier. SAM-2 (and
SAM)
require that a task identifier include an initiator identifier. Since it
appears that a fully qualified exchange identifier may not include an
address
identifier of initiator port, it is possible that a task identifier is
equivalent
to a fully qualified exchange identifier plus an address identifier of
initiator port. Note: I had a similar concern about the SAM-2 requirement
that a task identifier include a logical unit identifier (whose main
component of
interest here is a logical unit number). However, it appears that all
logical
units share the set of fully qualified exchange identifiers associated with
one initiator/target pair. Therefore, the fully qualified exchange
identifier
implicitly includes the logical unit identifier (and LUN).
Note: I believe that SAM-2 (and SAM) contain a bug in the definition of task
identifier and will bring a proposal on the subject to the next Protocol WG
meeting.

ENDL-40 Clause A.1 Table A.1, equivalence to task address. Using the
argument
found in comment ENDL-39, there is no need for a task address to contain a
logical unit number, as is currently shown in Table A.1. However, SAM-2 (and
SAM) contains a trick in the definition of task address. The logical unit
identifier is a key component of the task address. The logical unit
identifier contains two parts; a target identifier and a logical unit
number. Thus, task
address must contain a target identifier. Since it appears that a fully
qualified exchange identifier may not include an address identifier of
target
port, it is possible that a task address is equivalent to a fully qualified
exchange identifier plus an address identifier of target port."

GME: In ENDL-39, you state that that you believe that SAM-2 (and SAM)
contain a bug in the definition of task identifier.  What is it?

GME: In ENDL-40, you state that there is no need for a task address to
contain a LUN.  Both SAM and SAM-2 say it does.  Additionally, it must
contain a Target Identifier, (which we have shown to be equivalent to a Port
Identifier.)

GME: In both ENDL-39 and ENDL-40, you assert that a fully qualified exchange
identifier may not include an address identifier of the target port. I
missed that in my reading of FCP-2.4.  Why did you make that assertion?

|
|} Note, you can not directly address the "target/port"
|} at the SCSI ULP.
|
|If this statement is meant to apply to application
|clients, then it is both true and false.  

GME: Whoops, I missed Target Reset.  It does directly address target/port.  Although as I discuss latter, it is really a broadcast to the LU's.

|The SAM-2
|model under development prohibits sending a command
|to one target port and requiring that the data be
|transferred on a different target port, as such
|no naming mechanism is provided for identifying
|the different target port.  On the other hand,
|the application client addresses a SCSI command
|to a specific Target Identifier, which must of
|necessity address a specific target/port.

GME: With the exception of Target Reset, all other Task Management functions directly address a Logical Unit.  I agree that the target/port is part of the LU address.

|
|} All task management commands are ultimately
|} delivered to an LU's device server.
|
|This statement conflicts with SAM and SAM-2.

GME: I don't think so.  All Task Management commands are ultimately executed by one or more Logical Units. SAM and SAM-2 have equivalent definitions for Logical Unit.  SAM defines the Logical Unit this way:

Object definition 6: Logical Unit
Logical Unit = Device server + Logical Unit Number + Task Set

GME: The Device Server is the logical processor for an LU, not the Task Manager.   This leads me to think of the Task Manager as part of the Service Delivery Subsystem.  This would make it part of the Lower Level.

GME: Here is your reference:
"The task manager controls the execution of one or more tasks by servicing
the task management functions specified in clause 6. Its external address is
equal to the target identifier. As specified in object definition 5, there
is one task manager per target device.

The order in which task management requests are executed is not specified by
this standard. In particular, this standard does not require in-order
delivery of such requests, as defined in 4.6.2, or execution by the task
manager in the order received. To guarantee the execution order of task
management requests directed to a specific logical unit, an initiator
should, therefore, not have more than one such request pending to that
logical unit."

GME: Note that the words say the task manager controls execution by
servicing the task manager functions.  I understand how you are reading
this.  However, if we also look at the Task Management commands, we learn
more and come to a more complete, but not inconsistent, conclusion.  Here are
those commands:

Service Response = ABORT TASK(Task Address || )
Service Response = ABORT TASK SET(Logical Unit Identifier || )
Service response = CLEAR ACA (Logical Unit Identifier || )
Service response = CLEAR TASK SET ( Logical Unit Identifier || )
Service Response = LOGICAL UNIT RESET (Logical Unit Identifier || )
Service Response = TARGET RESET ( Target Identifier || )
Service response = TERMINATE TASK (Task Address ||)

GME: Note that all of these commands, with the exception of Target Reset are
specifically addressed to an LU, not the Task Manager.  So, let's look at the exception.

GME: Target Reset is addressed to the Service Delivery Port.  SAM - SAM-2.8 allow there to be one or more Service Delivery Ports per Task Manager.  So here again, the command is not addressed directly to the Task Manager.   The definition of Target Reset is that it executes a Hard Reset which by definition executes a Logical Unit Reset on each attached LU.  This is functionally equivalent to a broadcast of a Logical Unit Reset within a Target Device.  Thus a Target Reset is broadcast by the Task Manager to the Device Servers of all attached Logical Units.

|
|  "The task manager controls the execution of one
|  or more tasks by servicing the task management
|  functions specified in clause 6."
|
|} Some are broadcast to more than one.
|
|There is no broadcast function in SCSI.

GME: See above.  Target Reset -> Hard Reset -> Broadcast LU Reset

|
|} The port level LLP through task manager to ULP
|} device server mapping has always been LLP specific.
|} Addressing the target/port is an LLP operation.
|
|This represents a positioning of the Task Manager
|that I had not considered.  I always envisioned
|the Task Manager at the same layer as the Device
|Server, probably because the Application Client
|(clearly just one layer) addresses requests
|to both.

See above discussions.  All service requests from an Application Client are ultimately delivered to one or more Device Servers.  I think of these as the ULP entities.  I realize the spec is not clear on this, but I have come to think of the Task Manager as an LLP entity.  This view is consistent with SAM and SAM-2 if the description of Target Reset is explained in terms of a Broadcast Logical Unit Reset from Application Client to Logical Unit Device Servers.

Regards,
George Ericson 

CLARiiON Advanced Technology 
EMC Corporation, 4 Coslin Drive, MS C44, Southboro, MA 01772
Office: (508) 480-7349; Mobile: (508) 498-8461; Fax: (508) 480-7913

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