Death to I_T_L_Q nexus
Kevin D Butt
kdbutt at us.ibm.com
Wed Jun 11 11:22:36 PDT 2014
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406111_f.htm">HTML-formatted message</a>
I have no objections with the concept of this direction. I was initially
concerned with the terminology used since FCP-4 also used the term.
However, upon further review this seems to fall right into place.
Command Identifier = 3.1.7 command identifier: The information that
uniquely identifies a command. See Annex A and SAM-5. This is synonymous
with OX_ID (Note that If retransmission is enabled, the task retry
identifier is also used to construct the command identifier.)
I do have a concern with using "I_T_L nexus plus command identifier"
throughout all the standards. I would prefer we come up with a term to
describe this. Perhaps something like "Fully qualified command
identifier". I know that doesn't really save words or letters when typing
it, but it does better convey, I think, the concept for which it is used.
Annex terminology mapping seems to have inconsistencies in it.
For SAM-3 command identifier = task tag
For SAM-4 command identifier = I_T_L_Q nexus
I think, perhaps for SAM-4 mapping it should be "I_T_L nexus plus command
identifier = I_T_L_Q nexus"
Also, there is a typo of "poert" instead of "port" in 126.96.36.199 in the SCSI
Initiator Port box
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
From: George Penokie <george.penokie at avagotech.com>
To: T10 Reflector <t10 at t10.org>,
Date: 06/11/2014 08:35 AM
Subject: Death to I_T_L_Q nexus
Sent by: <owner-t10 at t10.org>
If don't reached SAM overload yet this proposal should push you over the
edge. Here is the overview:
There has been a long standing problem with the I_T_L_Q nexus as it
combines routing information with a command identifier. The routing part
is the I, the T, and the L. The command identifier is the Q. In addition
the nexus really does not have a satisfactory home in the SAM-5 UML
This proposal solves the UML issue by adding a Management Application
Client class that is a ?kind of? Application Client class. The new
Management Application Client class has I_T Nexus Identifier attributes
and I_T_L Nexus Identifier attributes. The Management Application Client
class is the class that goes out and finds all the nexuses in the SCSI
domain. The method used for the Management Client class to do this is
protocol specific. For example in SAS the discovery is defined in the SPL
This also separates Q from nexus and replaces that with a standard alone
attribute called a Command Identifier attribute. The effect of this is
that all the I_T_L_Q nexus terms will be replaced with either Command
Identifier or I_T_L nexus and command identifier. This causes extensive
changes to several standards but has the largest effect on SPL, then SAM,
then SPC, and finally SBC. To prevent issues with existing published
standards the term I_T_L_Q nexus will have to remain but it will be
defined as being synonymous with I_T_L nexus plus command identifier.
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
Bye for now,
3033 41 St NW
Rochester , MN 55901
george.penokie at avagotech.com
More information about the T10