07-438r0 suggests that we change "acts
as" a SCSI target/initiator port to "is" a SCSI target/initiator
port. and that we add the following to ADT-2:
If a port that does not support SCSI
target functions receives a SCSI Command IU or a SCSI Task Management IU,
then it shall transmit a NAK IU with a status code of UNSUPPORTED FRAME
TYPE FOR SELECTED PROTOCOL (see table 14) and discard the IU.
Note x: The exchange originator should
not interpret this response as an indication that the port does not have
SCSI target port capabilities, only that it does not have SCSI target port
capabilities enabled at this time (see 4.1).
Discussion about "acts as"
vs "is"
First, I think "acts as" is
more correct than "is". A port that is a SCSI target/initiator
port (this term does not exist in SAM-4) acts as a SCSI initiator port
and a SCSI target port.
SAM-4 states:
<<
Each instance of a SCSI Port class shall
contain:
a) one SCSI target port that shall contain:
A) one task router;
b) one SCSI initiator port; or
c) both.
>>
SAM-3 states:
<<
3.1.94 SCSI initiator port: A SCSI initiator
device object that acts as the connection between application clients
and the service delivery subsystem through
which requests, indications, responses, and confirmations are routed.
In all cases when this term is used
it refers to an initiator port or a SCSI target/initiator port <<operating
as>> a SCSI
initiator port.
and
3.1.99 SCSI target port: A SCSI target
device object that contains a task router and acts as the connection
between device servers and task managers
and the service delivery subsystem through which indications and
responses are routed. When this term
is used it refers to a SCSI target port or a SCSI target/initiator port
<<operating as>> a SCSI target port.
and
3.1.101 SCSI target/initiator port:
A SCSI device resident object that has all the characteristics of a SCSI
target
port and a SCSI initiator port.
>>
Discussion about adding the suggested
text:
The issue that this proposal intends
to solve is that of a port receiving a command IU when that port is an
initiator port only or that is an initiator/target port that has not yet
been configured to act as a target port. One of the concerns about
what is returned is that the port initiating this command IU not take the
rejection to mean that this port will never accept a command IU.
There are really two behaviors that
a plausible. One behavior is that mentioned in the proposal of the
transport layer returning a NAK IU with a status code of UNSUPPORTED FRAME
TYPE FOR SELECTED PROTOCOL. The other is to treat the port as being
a target port but not having a valid logical unit so the response would
be at a higher layer.
It seems to me that returning a LOGICAL
UNIT NOT CONFIGURED would be more accurate. Further it does not imply
that the logical unit does not exist or is not supported. It just
implies that it needs configured before it can be communicated with. This
is exactly the scenario we are in. The one concern I have with this
approach is that no LU exists and no well-known LU either.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/
"Banther, Michael"
<michael.banther@hp.com> Sent by: owner-t10@t10.org
11/26/2007 10:39 AM
To
"t10@t10.org" <t10@t10.org>
cc
Subject
ADI-2 teleconference
The ADI-2 working group will hold an ad-hoc
teleconference on 28 November 2007 starting at 8:00 AM PST and concluding
at 10:00 AM PST. You can find the agenda, including contact details,
at http://www.t10.org/ftp/t10/document.08/08-004r0.pdf.
The contents of this message and any attachments to it are confidential
and may be legally privileged. If you have received this message in error,
you should delete it from your system immediately and advise the sender.
To any recipient of this message within HP, unless otherwise stated you
should consider this message and attachments as "HP CONFIDENTIAL".