FCP Letter Ballot Results
John Lohmeyer
jlohmeye at ncr-mpd.FtCollinsCO.NCR.COM
Mon Mar 21 11:30:33 PST 1994
X3T10 Letter Ballot Results on FCP:
47 Yes, 2 No, 0 Abstain, 11 Did not return ballot
Yes, with
comment: IBM, Unitrode
No: FSI, Seagate
Did not
return ballot: Advanced Micro Devices, Cirrus Logic, Conner
Peripherals, Distributed Processing Technology,
Harting Electronik, Maxtor, National
Semiconductor, Oak Technology, P. E. Logic,
Rancho Technology, and Samsung
FCP has passed this ballot, but X3T10 must make an effort to
resolve the comments. Since Bob Snively, FCP Editor, cannot
complete this effort prior to the mailing deadline, the current plan
is for Bob to mail a revised FCP document directly to the X3T10
members at least two weeks prior to the May '94 X3T10 meeting.
A meeting to develop the FCP responses will be held in conjuction with
the April X3T11 and X3T12 meetings in Seattle. The meeting is planned for
Monday, April 18th. Contact Bob Snively for details.
Expect motions to approve the FCP responses and to approve the
substantive changes to FCP at the May meeting.
IBM comments:
1. FCP has no method of resetting an alternate port of a dual
port SCSI device without affecting the port being used.
Since Parallel SCSI has this capability (using a message),
FCP should also. A currently reserved bit of the Task
Management Flags field (Byte 2 of FCP_CNTL, p. 23) could
be used for this task. This function should reset all other
ports of a multiport device.
2. FCP states that ALL commands are resumed after a Clear
ACA task management function is received. The SCSI
Architecture Model (SAM) states that only non-ACA tagged
commands should be resumed and ACA tagged commands
should be aborted. FCP should be consistent with SAM.
(Please see p. 24, Clear ACA.)
Unitrode comments:
We would still like to have SAM approved first.
Minor editorial things:
5.3.9 Table 13 is referenced as table 12
6.2.1 Table 15 is referenced as table 14
7.4.1 There is no reference to table 21 as in all other sections.
FSI comments:
The following comments are provided to support a "NO" vote for Project
993D, Revision 8.
1. (E) Foreword, Line 2, Change "command," to "commands,".
2. (E) Introduction, Para. 1, Line 3, Change "performance serial" to
"performance Fibre Channel".
3. (E) Introduction, Para. 2, Line 1, Change "Sequences" to
"Exchanges and Information Units".
4. (T) 1 Scope, Para. 1, Line 1, Change "Upper Level Protocol (ULP)"
to "mapping protocol (FC-4)".
5. (T) 2 Normative References, Delete reference to SCSI-2 Standard.
It does not apply to this standard. Only SAM applies.
6. (E) 2 Normative References, Update Revision Level on FC-AL to
4.2.
7. (E) 2 Normative References, Update Revision Level on FC-FG to
2.1.
8. (E) 2 Normative References, Update Revision Level on FC-SB to
???.
9. (E) 3.1.12, Line 2, Change "a single sequence" to "an". The
Fibre Channel committee has requested that FC-4s not
mention sequences, except in a passing manner. Information
Units are to be referenced and Exchanges.
10. (E) General, as in Comment 9, Delete all references to the term
Sequence unless absolutely required to explain Fibre
Channel structure. The term "Information Unit" is to be used
instead.
11. (T) 3.1.12, Paras. 2, 3, 4, and 5. Delete. Move to an Annex or
leave as a reference to FC-PH, but delete details from the
Glossary of terms. The confusion about ULPs and FC-4s in
Comment 4 is evident in these paragraphs as well.
12. (E) 3.1.13, Delete sentence 2. The explanation in the second
sentence is not part of the SAM definition. This
definition needs to delete the "FCP" in its name. The
definition is the SAM definition for an I/O operation and is
not unique to FCP.
13. (T) 3.1.14, Change "L_Port" to "NL_Port". An L_Port refers to
either an NL_Port or an FL_Port in the Fabric topology.
14. (T) General, Change all other references to "L_Port" to "NL_Port"
unless the definition in Comment 13 is intended by the word.
15. (T) 3.1.15, In Clause 5.1, para. 1, the Responder X_ID (RX_ID) is
identified as optional. Therefore, the RX_ID field cannot be
used as a reliable part of the Fully Qualified Exchange ID.
The Fully Qualified Exchange ID therefore is only a 64 bit
value and is selected by the Initiator when an exchange is
started.
With the addition of permission to use the association header (see
clause 5.5.7) the use of FQXID as a stable reference for a task
identifier (see 3.1.33) is untrue. A fundamental assumption of SAM
seems to be a single, unchangeable identifier for the life of a
task. In Fibre Channel, FQXID is not a stable, reliable,
unchangeable entity as described here. Therefore, it use as the
basis for a task identifier is in doubt.
16. (E) 3.1.16, Delete "as a single sequence". See Comment 9.
17. (T) 3.1.17, Device service requests and task management functions
are handled by Logical Units in a target SCSI device. Both
SAM and FCP need to be updated to reflect this. SAM
identified these functions as part of the Logical Unit.
18. (T) 3.1.18, Delete reference to FC-PH. This is not a definition
found in FC-PH as the other references to SAM and FC-PH are.
19. (E) 3.1.22, Add the source of this borrowed definition (FC-PH or
FC-AL).
20. (T) 3.1.23, Add the definition of NL_Port.
21. (T) 3.1.24, The definition in 3.1.7 conflicts with this
definition. Each command has an explicit or implicit
transfer length. However, that length is not related to the
number of bytes transferred, except that the total bytes
transferred is greater than or equal to the number implied by
the command. This is consistent with error recovery
procedures that exists today in SCSI where the target and
logical unit are responsible to see to it that a sufficient
number of bytes are transferred in the correct locations to
provide coverage for the implicit or explicit transfer
length. However, the total number of bytes transferred by
the target may exceed this explicit or implicit count. This
problem occurs again in the description of the FCP_DL field
and the calculation of the residual count. A target must be
allowed, in a standard way to transfer more than FCP_DL bytes
to satisfy its responsibility to manage each command. (See
7.1.4 and 7.4.2.)
22. (T) 3.1.27, Change "task" to "command". Each command has a
status. Completion of task is implied by the status value,
but in FCP, completion is indicated in the choice of
Information Units used by the target when sending status.
23. (T) 3.1.28, In FCP, the Originator Exchange ID (OX_ID) uniquely
identifies a task from an initiator to a target. Unlike
SIP/SPI, FCP does not permit a tag value to be reused between
logical units as this definition implies. An OX_ID used for
any task to any logical unit from an initiator to the same
target cannot be reused for any other logical unit until the
task for the original logical unit completes. Therefore, FCP
limits the total number of tasks in a single target through
one port to 65535 from the same initiator, not 65535 per
logical unit as this definition states
.
24. (T) 3.1.29, Change "commands" to "tasks" or "I/O operations".
25. (E) 3.1.30, Delete the reference to FC-PH. The choice of
identifier is made by FCP and has nothing to do with FC-PH.
26. (E) 3.1.33, FQXID, as defined in 3.1.15 does not require RX_ID.
The Source ID, Destination ID and OX_ID are sufficient to
uniquely identify a task. The RX_ID field is optional and
should be dropped from the definition of both FQXID and task
identifier.
See comment 15. The FQXID value is not a stable reliable
identifier in FC-PH that can be used as an unchanging task
identifier for the life of a task. The Fibre Channel Association
header and the process of exchange ID reassignment can cause
changes to the OX_ID, RX_ID, S_ID and D_ID fields during the life
of an exchange.
27. (E) 3.3, Add a paragraph similar to the one below.
"In case of a conflict between text, tables and figures, the order
of precedence for resolving a conflict is text, tables, and lastly,
figures."
28. (E) Clause 4.1. The point-to-point topology, the Fabric topology
and the Arbitrated Loop topology each provide a service to
N_Ports or NL_Ports. FC-PH is a common transport service
that operates with any of these topologies. Delete paragraph
2 or reword it. Each SCSI device must choose from one of the
three topologies to connect with another SCSI device when
using FCP.
IF there is to be a topology discussion, it is best delegated to
an annex if it is needed at all in FCP.
29. (T) Clause 4.1, para. 3. A ULP uses the services of an FC-4, not
FC-PH. FC-4s use the services of FC-PH. FCP is to be
described in terms of Exchanges and Information Units (not
sequences). Change "L_Ports" to "NL_Ports". In line 4,
change "will be" to "are".
30. (T) Clause 4.1, para. 4. Fibre Channel ports are assumed to have
a common service interface for use by FC-4s (not ULPs) (line
2). An example of the interface from a SCSI initiator ULP is
specified in CAM. There is no equivalent for the target ULP.
31. (E) Clause 4.1, para. 6, top of page 6. Delete "and frame
structures". Fibre Channel FC-4s are not to deal with
frames, only information units. The term frame should not
appear in any FC-4. Each action between Initiator and Target
needs to be defined as an Information Unit.
32. (E) Table 1, line 3, Change "sequence" to "Information Unit".
33. (T) Clause 4.1, para. 7 (after Table 1). In SCSI, today, the
number of concurrent tasks has been limited by initiator and
logical unit implementations, not the port implementations.
FCP limits the level of concurrent tasks to attributes of
the port implementations and not the Initiator or Logical
Unit. That is, the two ports used between an initiator and
target may limit the task concurrency to a level below that
of the initiator and logical unit implementations. A
physical port change, rather than a possible firmware change,
maybe required to increase the amount of concurrency. This
is not consistent with other SCSI mappings. This limitation
must be clearly stated since it is contrary to current
practice and other SCSI-3 protocols.
34. (E) Clause 4.2. This clause needs to be marked as "Informative".
35. (E) Clause 4.2, paras 1, 2, The term FCP I/O Operation includes
more than just commands or lists of commands. Only the term
"task" is appropriate here.
36. (E) Clause 4.2, para. 2, Lines 1-2, Change "unsolicited command"
to "Unsolicited Command" (See Table 1. See earlier
discussion of using FQXID as the task identifier. The RX_ID
field is optional and is not available to the initiator until
AFTER the first command of each task is sent to the target.
Then X_ID reassignment may change the values of the FQXID
over time.
37. (E) Clause 4.2, para 2, line 6, Change "transfers" to "IUs".
38. (E) Clause 4.2, para. 3, line 3, Change "described" to
"describes".
39. (E) Clause 4.2, para. 3, line 4, Change "solicited data sequence
" to "Solicited Data IU".
40. (E) Clause 4.2, para. 3, line 5, Change "information" to
"payload".
41.`(E) Clause 4.2, para. 3, line 6, Change "described" to
"describes".
42. (E) Clause 4.2, para. 3, line 6, Change "solicited data sequence"
to "Solicited Data IU".
43. (E) Clause 4.2, para. 3, line 7, Change "information" to
"payload".
44. (E) Clause 4.2, para. 3, lines 7-8, Change "Data delivery
request" to "Data Delivery Requests". (See Table 1).
45. (E) Clause 4.2, para. 4, line 1, Change "transferred" to
"transferred (if any)".
46. (E) Clause 4.2, para. 4, line 1, Change "command service request"
to "Command Service Request".
47. (E) Clause 4.2, para. 4, lines 2-3, Change "Status Byte" to
"Status".
48. (E) Clause 4.2, para. 4, line 4, Change "command status response
is the last sequence of the Exchange and terminates the FCP
I/O Operation" to "Command Status IU terminates the command.
The choice of Information Unit type determines whether the
task ends or continues to another command.".
49. (E) Clause 4.2, para. 5, Page 7, Change "FCP I/O Operation" to
"command".
50. (E) Clause 4.2, para. 6, line 2, Change "FCP I/O Operation." to
"task. The choice of IU from the target determines whether
the task continues.".
51. (T) Clause 4.2, para. 7. This concept of task concurrency
limited by the choice of the port you buy for FCP must be
clearly stated. Those not familiar to the concepts for
identifying tasks for FCP may not recognize that, unlike SCSI
SBP, the queue depth is determined by hardware and not
software. If this method of limiting concurrency is
acceptable to the X3T10 committee, FCP must clearly state it
as a limitation and warning to potential users of FCP.
52. (E) Clause 4.2, para. 8, line 2, Change "sequences of FCP I/O
Operations" to "IUs of FCP".
53. (T) Clause 4.2, para. 8, line 3. If "interlocked IU transmission"
is part of FCP then it must be described here to permit Class
3. However, the proposal to use FCP in Class 3 on the
arbitrated loop does not require interlocked IU transmission.
Therefore, this requirement must be removed.
54. (T) Clause 4.3, Page 7, para.2, line 3, Change "sequence" to
"IU".
Unlike SIP/SPI, the limitations of a Fibre Channel port to start
a new exchange may limit the ability of an initiator to perform
task management functions in a timely manner. For example, if the
limit of the number of concurrent exchanges is reached between an
initiator and a target (across all logical units), the initiator
is unable to start a new exchange to perform task management
functions. This is a potentially serious limitation since each
initiator must not attempt to use the last exchange it has
available with each of N targets to be able to start the
appropriate task management functions when required to each target.
This operational limitation does not exist in the other protocols.
If this behavior is acceptable to the X3T10 committee, this
limitation must be placed in the standard as a warning to
implementors. This limitation is not obvious to those who have a
casual acquaintance with Fibre Channel and may cause serious
implementation or operational difficulty if not fully understood
and plainly stated in the FCP standard.
This problem of allocation of concurrent open exchange resources
in a port also requires low level resource allocation in the
initiators and targets that is not currently required in the other
SCSI mappings.
55. (E) Clause 4.3, para. 2, line 3, Change "CDB of" to "FCP_CDB
field in".
56. (E) Clause 4.3, Table 2, line 2, column 2, Change "Login/Logout"
to "Process Login/Logout". Login and Logout (without the
"process" adjective) has an entirely different meaning in
Fibre Channel.
57. (T) Clause 4.3, Table 2, lines 2, 7, and 8. These functions
should be mandatory in the FC-4. The capability to perform
these actions is dependent on the SCSI ULP, especially the
last two. They are discoverable attributes managed by the
Inquiry data and the ACA field of the CDB. The FCP FC-4 must
be able to manage these functions when the Initiator and
logical units agree to use the functions. This it the first
of several instances where the FC-4 appears to be arbitrarily
limited when interoperability from some profile is a logical
constraint. The FCP-FC-4 must support the functions.
Whether they are invoked or not is up to the ULPs and not of
concern to the FCP FC-4 or the ports. As a general rule, any
functions that are logically managed SHALL be supported by
the FC-4. Otherwise, a SCSI device may implement a function
which cannot be performed because of the choice of FC-4 or
port manufacturer.
58. (T) Clause 4.4 and Table 2. The FC-4 must support this function
if called upon to perform it. The ULP is not obliged to
support it. That is, implicit process login is a function of
the ULPs and not of either the FC-4 or the FCP_Ports.
59. (T) Clause 4.4, para. 1, line 3, the concept of "multiple images"
has been added and appears to violate the definition of
unique initiator or target identification based on the S_ID
or D_ID field values as specified elsewhere in FCP. Since it
appears that adopting the FC-SB Process Login/Logout protocol
introduces the concept of multiple images, the ULPs cannot
depend on the S_ID field to unequivocally identify the
initiator or the target. The process associator permitted
with this type of process login and the rules for use in FC-
PH adds a new identifier potentially for either the initiator
or target or both which is NOT an alias of the S_ID or D_ID
values. The S_ID and D_ID identify generally which
initiators or target images are involved, but not exactly.
An optional header is required to uniquely identify the
initiator or target. This is contrary to other parts of FCP.
60. (E) Clause 4.5, para. 1, line 2. Primitive Sequences (notice
capitalization from FC-PH), are not associated with either
basic or extended link services. Reword the second sentence
to correct this implication. Change "frames" to "Sequences".
All basic and extended link services are a implemented as an
exchange of Sequences.
61. (E) Clause 5.1, page 9, para. 1, line 1, Change "fibre channel"
to "Fibre Channel".
62. (T) Clause 5.1, para. 1, line 2. After Process Login with
process associators required, the FQXID no longer identifies
either the initiator or the target or both. Identification
depends on the contents of the optional header called the
Association Header. This paragraph and the concepts of
initiator and target identification in FCP require rethinking
and reworking before it we have a workable set of definitions
and unequivocal identification of initiators and targets.
63. (E) Clause 5.1, para. 2, line 1, Delete "SCSI Devices and".
64. (T) The FQXID is not a stable value when X_ID reassignment is
active by either SCSI Device. A new handle to provide
unequivocal identification is required.
65. (T) Table 3, page 10, Row T3, Change the M/O column value to M.
The FC-4 must be capable of supporting the processes of the
Initiator and Logical Units.
66. (E) Table 3, page 10, Row T5. There must be a set of values
chosen for this action. In Fibre Channel, either Sequence
Initiative (SI) is transferred or it is not. The standard
cannot be ambivalent. Fill in the value needed to correctly
cause the processing intended.
67. (T) Table 3, page 10, Note 4, Change T10 to T11.
68. (T) Table 4, page 11, Rows I4 and I6, Change the SI values to
acceptable values. Even though these are the last
information units of an I/O process, valid sequence
initiative values are required by Fibre Channel to be placed
in the header fields.
69. (T) Table 4, page 11, Row I5, Change the M/O column value to M.
The FC-4 must be capable of supporting the processes of the
Initiator and Logical Units.
70. (E) 5.3. Move this entire clause to Annex A. It is purely
exemplary material.
71. (E) Tables 5 - 13, Change "UI" to "IU".
72. (T) 5.3, para. 1, line 3, Move the sentence beginning "Sequence
streaming...." to clause 5.2. This is an allowable option
for an implementation and needs to be removed from these
examples.
73. (E) 5.3, para. 1, line 4, Delete the last sentence.
74. (T) 5.3.9, the Abort task function cannot be accomplished using
any IU defined in the standard. An example of how it is
proposed to be handled needs to be given. The ULP is not
aware, or should not be aware that Fibre Channel is being
used. Therefore, an FC-PH link level request is beyond its
power to request. Explain the sequence of events that causes
this action to be taken.
75. (T) 5.4, para. 1, line 8, The concept of "interlocked IU
transmission" is not defined. This concept must be defined
since there is a proposal to operate FCP using class 3. This
process is a required operational procedure that must appear
in FCP.
76. (T) 5.5.2 and 5.5.3, The FQXID is improperly defined when the FC-
4 login indicated that process associators are to be used.
The D_ID and S_ID fields do not correctly define the
initiator or target in this case. Since the FC-4 login is
required, the proper identifiers must be made clear in all
circumstances and not left out of the standard. When process
associators are being used, the S_ID and D_ID values may
change over the course of a task and still the integrity of
the task between an initiator and a logical unit is correctly
maintained. I realize that in one of the industry group
profiles that process associators are not permitted, but this
is the FCP standard and not that profile. The standard must
reflect the true power and flexibility permitted by the tools
in FC-PH. The FC-4 login/logout process adds a new dimension
to naming initiators and targets. The name is loosely
coupled to a SET OF PORTS and not to a single port as occurs
in SIP/SPI. Refer to Annex R in FC-PH for managing exchanges
with association headers. This area is not complete in FCP.
77. (T) 5,5,9, para. 1, line 2. This restriction on not being
allowed to use an OX_ID of 'FFFF'h. FC-PH permits this value
which allows only one exchange between a port pair. This is
very similar to the "untagged I/O process mode" in SCSI-2 and
untagged tasks in SAM. This value should be allowed. A note
about the effect might be appropriate, but the value should
not be prohibited. In simple systems only one resource may
be all that is needed and FC-PH permits such a simple
implementation. FCP is not reduced in any way or otherwise
incorrect if this value is permitted.
78. (E) 5.5.11, para. 1, First, both the initiator and target have
base addresses. This is not exclusively a property of an
initiator. Second, the base address inside either SCSI
device is never exchanged with the other in FCP so a long
discussion is of little value. Relative offset requires more
work since the casual reader may have no idea about the
management of relative offset in FC-PH. Therefore a
discussion is warranted and the rules should be very clear.
Relating the relative offset use to IUs by name is a way to
simplify this problem.
79. (T) 5.5.11, Para. 1, lines 4-5. The base address does not refer
to the first byte of any IU. In category 5, there is a
header of 12 bytes in front of the data bytes of interest to
the SCSI device. This error must be corrected.
80. (T) 5.5.11, para. 1, lines 5-6. An option is given without a
definition of the means to decide when and if it can be used
by an initiator and a target. This means must be specified.
81. (E) 6, para 2, line 5, Change "acceptance" to "acceptance or
rejection". On the same line, change "acceptance or
rejection to" to "response to".
82. (T) 6.1, para. 1, line 2, The concept of "process images" is
unknown in SCSI and requires development and explanation on
its function and use in SCSI-3 since the text permits use of
this function of FC-PH by initiators and targets. A
reference to FC-SB is insufficient. Paragraph 2 also has
text about multiple images that must be corrected, if
required. The SCSI-3 actions specified for receipt of a PRLI
seem to indicate that only one at a time is valid. Is
something missing?
83. (E) 6.1, para. 1, line 3, last sentence. It is not obvious that
Table 14 permits more than one process associator in each
direction. Please explain the mechanism or delete the
sentence or indicate that the login may be used more than one
time, if that is the case.
84. (T) 6.1, Since the PRLI is like an IU, it must be described as
such with all of the values for the header fields clearly
stated in the standard. The accept is not a normal frame so
that must be explained and the frame header contents also
specified.
85. (T) 6.1, para. 5, The contents of the SENSE KEY and ASC and ASCQ
fields are not specified. If existing values are to be used,
they must be specified. If new values are required, a
proposal must accompany specification of this behavior
specifically for the FCP standard. Do other protocols have
protocol specific responses not yet proposed to X3T10?
86. (T) 6.1, para. 5, line 2, the Unit Attention is "reported" not
transmitted. Since asynchronous event reporting is optional,
the Unit Attention must be queued until the initiator starts
a task, and then only reported for certain commands.
87. (T) When a new initiator logs in with a target, it should not
cause the equivalent of a Target Reset, which is the reaction
specified. There seems to be no need to report that a new
initiator has logged in with a target. There is no such
behavior in SCSI-2 or in any of the other protocols. This
specification seems to create an undue instability in the
system. Note also that since targets can login to
initiators, an intermittent use device, like a scanner, can
totally destroy a system environment by the simple act of
logging in. This action must be altered to not be so
disruptive.
Also, since the login procedure is symmetrical, what is the
reaction of an initiator that is logged in to by a target. That
is, if the target sends the PRLI, is the initiator reset. I
believe that it must be to be consistent with the behavior required
of targets when they receive a login.
88. (E) 6.1, para. 5, line 3, Change "sate" to "state".
89. (T) 6.1, para. 5, line 3, Reword the sentence beginning "No
tasks...." to state that all tasks shall be aborted, no
status is returned for any task, and all reservations are
released by the affected SCSI device. See comment 87 for
symmetrical behavior requirements in this area for
initiators.
90. (T) 6.1, para. 6. Every device must have some default PRLI
payload values. What is does not know is the default of the
other SCSI devices with which it communicates. Storing
information by S_ID or D_ID is not acceptable. The Fabric or
arbitrated loop may cause the physical addresses of the ports
to be reassigned.
Therefore, it seems that PRLI is explicitly required between any
two SCSI devices before they can communicate using I/O Operations.
That is, one device may have its defaults set to Command/Data Mixed
Allowed and the other one have that attribute prohibited. These
two SCSI devices will not communicate effectively.
91. (T) General, As noted in the comment 90 above, since the S_ID is
probably more unstable a value than a SPI SCSI device
address, how is MODE/SELECT-SENSE parameter saving managed
with FCP?
92. (T) 6.1, para. 7, Receipt of a new PRLI is not so much a request
to modify as it is to perform an implicit logout and a new
login. It should be stated as such and the rules for
behavior then restated in this light.
93. (E) 6.1.1, Word 0, Bits 3-24, para. 1, line 1, Change "16-byte
set" to "PRLI".
94. (T) 6.1.1, Word 0, Bit 15, paras. 1-2, Change "word 2" to "word
1".
95. (T) 6.1.1, Word 0, Bit 14, paras. 1-2, Change "word 3" to "word
2".
96. (T) 6.1.1, Word 3, Bit 4, para 1, line 2, Change "2 and 3" to "5
and 4".
97. (T) 6.1.1, Word 3, Bit 4, para. 1, top of page 20, Define a
response of FCP_RJT.
98. (E) 6.1.1, Word 3, Bit 3, para. 1, line 2, Change "data are" to
"data shall be".
99. (E) 6.1.1, Word 3, Bit 3, para. 1, last sentence, The only time
these parameters are exchanges is during a PRLI exchange.
This sentence does not make sense. Perhaps it should be
deleted.
100.(T) 6.1.1, Word 3, Bit 3, para. 2, The relationship between Word
3, Bit 3 and Word 3, Bit 0 must be stated in a table. There
are at least two valid combinations acceptable. Paragraph 2
states one rule, The term "write operation" is undefined.
101.(E) 6.1.1, Word 3, Bit 2, para. 1, line 2, Change "data are" to
"data shall be".
102.(E) 6.1.1, Word 3, Bit 2, para. 1, last sentence, The only time
these parameters are exchanges is during a PRLI exchange.
This sentence does not make sense. Perhaps it should be
deleted.
103.(T) 6.1.1, Word 3, Bit 2, para. 1, The relationship between Word
3, Bit 2 and Word 3, Bit 1 must be stated in a table. There
are at least two valid combinations acceptable. The term
"read operation" is undefined..
104.(T) 6.1.1, Word 2, Bit 2, para. 1, There seems to be no rationale
for unconditionally using I^ or I& as the only response when
data and response may be combined in one IU. A check
condition between bursts can cause the last response for a
command to be I4 which violates the "shall" in this
paragraph. Also, a Terminate Task message can cause the same
behavior. Therefore, a target is granted PERMISSION to use
IUs I6 and I7, but it shall not be required to use them as
the only means of response.
105.(E) 6.2, para. 1, line 2, Change "pairs" to "pair. No case for
sending multiple pairs has been established.
106.(T) 6.2, para. 1, Since either SCSI device may logout, the
behavior for initiators receiving the logout must be
specified. It appears that both devices are forced into
reset when either logs out or logs in. This is extreme
behavior and probably should be rewritten. The dynamic
behavior of systems means that a lot of disruption occurs for
no valid reason. Such behavior has not been part of SCSI in
the past and it does not appear in other protocols. Perhaps
it is overkill here, too.
107.(E) 6.2.1, Word 0, Bits 31-24, Change "16 byte set" to "PRLO".
108.(T) 6.2.1, Word 0, correct all word references for words 1 and 2.
109.(E) 7.1, It should be clearly stated that the first 8 bytes of
the FCP_CMND IU are controlled by FC-PH and not subject to
change. This is a side effect of using category 6.
110.(T) 7.1.1, para. 2, line 3, Change "device at the FCP_Port" to
"Logical Unit". SAM has no assumption that one logical unit
in a target has any cognizance of or information about the
next Logical Unit if any. The behavior identified in this
paragraph is contrary to both SAM and historical SCSI target
operation. Therefore, one Logical Unit is to be considered
totally independent from the next. The only thing in common
may be sharing a common access port to the service delivery
subsystem. Therefore, no hint about internal address
structure or other information can be guaranteed to be
available from or desirable from Logical Unit 0.
The wording in this paragraph has not been accepted by the X3T10
as acceptable standard behavior. We deleted the concept of a
target routine which is a more likely spot to find such information
since it must route information to the Logical Units, but that
still means that the Logical Units are independent. I realize that
the 64-bit address space used with FCP is too large to poll, but
Logical Unit 0 has been allowed to be and should remain an
independent entity as it historically has been.
Find some other mechanism for determining the Logical Units that
exist in a Target than the one specified here. Also, this text
seems to assume a homogeneous set of Logical Units per target -
that too is not an acceptable assumption.
Is the address structure in Annex B the one accepted by X3T10 for
SCC model devices? Since the project is just in the approval
process, this assumption in FCP seems to be in error. If it were
worded as one way to approach the problem that might be
instructive, but I don't think it is necessarily THE way.
111.(T) 7.1.1, para. 2, line 1, Change "command" to "I/O operation".
Delete the second sentence. In the INQUIRY command, if the
command is sent to an invalid logical unit, a response is
generated. There has been no proposal to change that
behavior in SPC. Therefore, some commands may respond with
invalid logical unit selection, but at least one command has
an alternative behavior. If the behavior as stated is
accepted, all targets on all protocols require the same
response and some of the values in the Qualifier field, or
the entire Qualifier field may be eliminated from the INQUIRY
response. With the behavior specified, no information about
potential logical units is available.
112.(T) 7.1.2, Table 17. If the terminate task function can be
accomplished by an IU, then the Abort Task function can also
be accomplished by an IU. If this is not true, then the
Terminate Task function must follow the model of the Abort
Task function. The constraints on access to the logical unit
are the same when either task management function is
required. They should be handled in a similar fashion. The
single exception for handling the Abort Task function is
curious. If sequence initiative is not available, as it may
not be in either case, use the request sequence initiative
protocol and then send a common IU. Define Byte 2, bits 4,
3, or 0 as the Abort Task function. See the definition of
Terminate Task on page 24. Abort Task should behave in a
similar consistent fashion.
113.(T) 7.1.2, page 24, CLEAR ACA, Delete the last two sentences.
This behavior has no business in FCP or in any other
protocol.
114.(T) 7.1.2, General, Since a new exchange is required to perform
several of these functions, the Initiator and Target must
never use their last exchange resource for a normal task.
Unlike SIP/SPI, the maximum number of tasks that can be
outstanding is as much a function of the port you buy as the
firmware you use. This restriction must be clearly stated
each time the problem arises. In SIP/SPI the maximum number
of concurrent tasks is controlled strictly by firmware and
the protocol is not involved. With FCP, the FC-PH protocol
can be a major limiting factor on the ability to start
concurrent tasks.
115.(E) 7.1.2, pages 24-25, Target Reset, para. 3, Change "N_Port" to
"FCP_Port" in 5 places.
116.(E) 7.1.2, page 25, Clear Task Set, para. 3, Change "N_Port" to
"FCP_Port" in 6 places.
117.(T) 7.1.2, page 25, Abort Task Set, para 1, Delete the two
sentences starting at "The bit is optional in FCP.". FCP
cannot restrict those functions delegated to Initiators.
Therefore, it shall be permitted otherwise, incompatible FCP
devices result. That is, one device uses the Abort Task Set
request and the other does not. This incompatibility is not
acceptable. Neither should FCP presume to know the protocol
and content of the requests since these are ULP functions and
not FC-4 functions. Substitution of one action for the other
violates the layering rules we are trying to establish in
SCSI-3.
118.(E) 7.1.2, page 25, Abort Task Set, para. 3, Change "N_Port" to
"FCP_Port" in 3 places.
119.(T) 7.1.2, page 25-26, Abort Task, Implement it in the same way
as Terminate Task. They are similar. The procedure for
terminating a task and aborting a task are similar and are
logical functions, not FC-4 functions. Handle them using a
similar protocol.
120.(E) 7.1.2, page 25, Abort Task, para. 1, line 6, Delete
"switching". Change N_Port to FCP_Port in para 3 also.
121.(E) 7.1.2, page 26, Execution Management Codes, add "Byte 3" to
the end of the topic label.
122.(T) 7,1,2, page 26, Write Data. FCP must specify the behavior
should an initiator set both the read and write data fields
to 1b. No behavior is specified. It is insufficient to
prohibit initiators from doing this.
123.(E) 7.1.3, para. 2, line 3, Change "nor examined by the Target"
to "and shall be ignored by the Target. The shall is needed
here.
124.(T) 7.1.4, Specify the relationship between zero and non-zero
values in this field and the Execution Management Codes in
Byte 3.
125.(E) 7.2, para. 1, line 1, Change "responder" to "Target".
(E) 7.2, That this is an optional function is never stated. If
required, it shall be used, but it is also permitted to not
use this IU with agreement from the other SCSI device. This
needs to be stated in the text.
127.(T) 7.2, para. 3, line 3, Change "is required to" to "shall".
Delete the last sentence in this paragraph since it is
implied by the shall added here. If the initiator cannot
supply the entire length, what behavior does it do to inform
the Target and what is the target's behavior in return?
128.(T) 7.2, para. 4, line 1, Change "target transfers to the
initiator" to "target shall transfer to the initiator in the
next IU". If the target does not transfer the stated amount,
what is the initiator behavior?
129.(E) 7.2, It should be stated that the contents of the first 12
bytes of Table 19 are controlled by FC-PH and not subject to
change. This is a side effect of using category 5.
130.(T) 7.2.2, para. 2, Add "The value in this field shall not exceed
the maximum burst length defined by the Disconnect-Reconnect
Page of MODE SELECT/MODE SENSE. (See 7.3, para. 2.)
131.(T) 7.3, para. 3, line 1, The lowest relative offset field value
of an FCP_DATA IU is all that is required to reassemble. The
SEQ_ID is only useful in an FCP_Port within an IU.
132.(T) 7.3. para. 3, line 4, What shall an initiator do if the RO
mismatch occurs on its end of the link?
133.(T) 7.3, para. 4, lines 2-3, Change "exact length" to "exact
location and length".
134.(T) 7.3, para. 5, The total amount of data transferred, at least
in SCSI-2 and SIP/SPI, represents only the maximum
displacement from the base address that any byte may be
placed by a target. In SIP/SPI, a target is permitted to
retry, resend, and overlay data as long as this maximum
displacement is not violated and no unfilled displacements
are present.
This rule should apply to FCP as well. It is the target's
responsibility to get the data any way it can to the initiator.
The major difficulty in SCSI-2 was that Modify Data Pointer was
optional and often not implemented by initiators. That function
has been made mandatory by the targets ability to use any offset
it desires in a FCP_XFER_RDY IU.
Therefore, a target should only be limited by the prevailing rule
and not some artificial limitation. The value in this field is
similar to the value a device driver gives to a Host Adapter.
However, that value does not affect Target behavior. Obviously,
if the displacement range were to be violated, the initiator has
many tools to stop the Target. These should not be blind transfers
and overlapped transfers have been permitted and should be allowed
to continue. Certainly, the mechanism for setting and adjusting
either the initiator or target addresses is platform dependent and
therefore under control at all times.
If the target executed a command and needs to transfer more data
than is allowed by the FCP_DL field, the ;command cannot end
normally. It must end with more then just an indication in an FCP
dependent field.
This function should not be exported to the opposite end of the
link.
135.(T) 7.3, para. 6, page 28, The last transfer is signaled by
selecting a different IU. the technical FC-PH text needs to
be changed to reflect IU choices. The same argument about
FCP_DL applies to write operations. The target is
responsible for its own internal operation. If it has an
internal memory failure it should be allowed to retransmit
information.
The only limitation is that it not be allowed to violate the
maximum displacement rule in the comment above. The initiator
should not care whether multiple transfers occur. the target is
ultimately responsible to transfer all of the correct bytes from
displacement 0 to the maximum it determines from the CDB, not the
FCP_DL field. If the initiator disagrees, it has the tools to
stop the target. This is an unnecessary rule and very limiting
compared to the other protocols.
The target should never transfer excess bytes and therefore it
should not have excess bytes to discard. Clause 7.1.4 says that
it is the expected number of bytes. It is probably better worded
as the maximum displacement to be transferred from a base address.
This is consistent with how it has worked in the past. Only the
displacement is tested for error, not multiple transfers of the
same data.
136.(T) 7.3, para. 7, page 28. This paragraph is totally
inconsistent with the previous two paragraphs. A Target
cannot both be allowed to overlay data and not exceed the
FCP_DL count. There is a basic problem here. If the target
is capable of selecting any relative offset within the valid
displacement range, an initiator is already prepared to put
data anywhere. In case of a link error and overlay is not
permitted, a command must be aborted according to the present
rules since some of the data would be transmitted twice. This
seems too rigid to leave in FCP. Since SIP/SPI initiators
are required to permit some overlay, then FCP initiators
should be required to support overlay.
Further, FCP is ;not complete id the text must depend on a vendor
unique response when an overlay occurs. If overlay is or is not
to be permitted, just add it to the PRLI where the other
negotiations seems to occur. A vendor unique response is
unacceptable a standard solution if it is needed is required.
137.(E) 7.3, para. 8, page 28, line 2, Change "been transferred" to
"been transferred at least once". This is consistent with
SIP/SPI behavior and other protocols. Then the rule about
unused displacement ranges is totally correct. If it cannot
be transferred error free, at least once, the command does
not report that data above the hole has been transferred.
This is also totally consistent with the notion that the data
is not valid until after good status has been transferred
throughout SCSI.
There really seem no reason to have the FCP_DL value sent to the
Target at all. If there is an error, the initiator must stop the
target with the tools it has. Data overlay of all or part of the
data should not be a problem for either a target or an initiator
since it has been required of initiators and permitted by targets
since they SCSI targets to disconnect in SCSI-1.
138.(T) 7.3, para. 9, line 2, Change "is" to "shall be". Add a set
of rules about initiator and target behavior if the relative
offset is incorrect.
139.(E) 7.3, para 10, line 2, Change "effective" to "in effect".
140.(T) 7.4, Table 20, FCP_RESID field and accompanying text. Delete
this field. This field is a function of the initiators
internal workings and should not be exported for target
control. It is double work for some logical units since a
residual is reported in the Information Bytes of the sense
data. Since the sense data is in the form of Autosense,
there is no reason to duplicate functions.
141.(T) 7.4.1, Byte 2, Bits 3-2, These fields are not really needed
as stated above. The basis for any calculation is an
estimated value. The real value for the data length only
comes from the CDB itself and other attributes known to the
Logical Unit. Therefore, if the initiator sets its FCP_DL
value on platform boundaries of 4 or 8 bytes, almost every
command could end with a FCP_RESID_UNDER indication with no
real errors in the system. For device classes other than
disk this could be a common occurrence. But those device
classes already have the mechanisms to report residual
counts. This is redundant and not properly a logical unit
function to report in this manner since both the source and
reporting are outside the bounds of the command structure of
SCSI. If we need to invent new commands for some reason then
lets do that, but not invent a protocol specific command
subset.
142.(T) 7.4.2, para. 1, line 4, Change "value is not be valid" to
"value is not valid". Note that for the sequential device
class, the control of the residual counts is fully
architected within the command set. The presence of the
FCP_RESID requires reporting items in a mandatory fashion
that have been eliminated by agreements between the involved
parties. This field should also be deleted. This becomes a
performance issue once again where it was fixed in SCSI-2.
Any non-zero value in FCP_STATUS requires analysis even when
the status is GOOD as it is with may tape operations where
the lengths would not match under this scheme.
143.(T) 7.4.2, paras. 2-3, The calculation of FCP_DL does not permit
overlaying of data as permitted in clause 7.3. This
discrepancy and inconsistency must be corrected.
144.(E) 7.4.4, para. 2, line 2, Add a period at the end of the
sentence.
145.(T) 7.4.5, para. 1, line 1, There should be no reference to SCSI-
2 sense data, SPC is the only valid reference point for this
information. The rules about minimums and maximums and
presentation should be deferred to SPC and the text removed
from FCP.
Also, there is no requirement that I can determine that
FCP_SNS_INFO must be used at all times. That is, if a CHECK
CONDITION or COMMAND TERMINATED status occurs, the logical unit
could revert to waiting for the Initiator to request the sense
data. That option should be available to logical units and FCP
should not force a behavior. It can provide a note that sending
Autosense data is encouraged, but it has not right to demand it.
146.(E) Annex A. This should have clause 5.3 incorporated into it
and the examples removed from the main body of the standard.
147.(E) Annex A, This Annex should indicate that its examples are
for Class 2 only.
148.(T) Annex B. Delete this annex. Any discussion about logical
unit addressing belongs in SAM, not here. FCP is required to
provide a field up to 64 bits long. It has provided the
maximum length field. Any discussion about the structure of
the field is inappropriate in any of the protocol standards.
If a proposal is required for SAM, then this may be a basis
for that. However, this structure is not generally
applicable and may be best delegated to SAM or even SCC.
Seagate comments:
1) The referenced document should be rev 8 rather than 7.
In this instance my vote is an organizational one since the balance of
the comments were provided by engineers developing our FCP design.
Resolution of the following comments would allow my vote to be changed
to yes.
T 001 Page 17, Section 5.5.10
Use OX_ID=FFFF to indicate an untagged command, and drop the "untagged"
task management bit (page 24, section 7.1.2). Such usage is consistent
with FC-PH section 18.9.
E 002 Page 18, Section 6.1, Para 5
"sate" s/b "state"
"effected" s/b "affected"
E 003 Page 18, Section 6.1, Para 5
Needs clarification: by stating that "Mode Select parameters will assume
their default or saved states for that image pair" it is implied that
other image pairs are unaffected, but this is inconsistent with the
target being in "the same state as after a power-on or hard reset."
Also, it is not true that the target will be in the same state as after
a power-on since login sessions with other initiators must survive.
T 004 Page 18, Section 6.1, Para 5
What Additional Sense Code should be returned with the Unit Attention?
T 005 Page 18, Section 6.1
If targets must dump tasks for other initiators on PRLI, they should be
aborted with ABTS-LS as required for Target Reset and PRLO, rather than
just being cleared.
T 006 Page 18, Section 6.1
Having the target dump all tasks and reservations for all initiators when
an initiator does a PRLI accomplishes nothing and wastes time. The new
initiator can issue a Target Reset after PRLI if it wants the target in
this state. The appropriate place to behave this way, and this should
be specified in FCP, is after a target NL_Port engages in loop
re-initialization, or a target FCP ports participates in the Link Reset
protocol.
T 007 Page 18, Section 6.1, Para 5
To summarize comments on this section, suggest wording paragraph 5 to
have the following meaning:
Immediately after the execution of a PRLI, a target will have no tasks,
reservations, or status present for the other port involved in the PRLI.
Mode Select parameters will assume their default or saved states for that
image pair. Tasks, reservations, status, and Mode Select parameters for
other initiators are not affected. A unit attention condition as defined
in the SAM is generated by the target port for the initiator port with
Additional Sense Code indicating power-on reset or hard reset. A target
port shall not generate a unit attention condition for initiators which
are already logged in.
T 008 Page 19, Section 6.1.1, Initiator Function and Target Function
Unclear whether usage of AEN or other role-reversals would require both
bits to be set by both targets and initiators. Information is lost if
so: a host is interested in who is primarily an target, not in who is a
target only for the purposes of AEN. Could define new bit flags to
indicate whether limited role reversals appropriate to their primary
functions are supported. Better yet, reword as follows:
Word 3, Bit 5: Initiator Function
When this bit is set to 1, the process is indicating that it operates as
a SCSI Initiator. ... Initiators may implement some target functions
without setting the Target Function bit; the use of these capabilities
by a target is defined by Mode Select parameters.
Word 3, Bit 4: Target Function
When this bit is set to 1, the process is indicating that it operates as
a SCSI target. ... Targets may implement some initiator functions without
setting the Initiator Function bit; the use of these capabilities by a
target is defined by Mode Select parameters.
T 009 Page 20, Section 6.2 (PRLO)
The state after a PRLO is NOT equivalent to a power-on or hard reset, as
other ports are not logged out.
E 010 Page 20, Section 6.2
The effect on Mode Select parameters for other initiators is not clear.
Should behave in same manner as PRLI.
T 011 Page 20, Section 6.2
No reason to abort all tasks from all initiators, just the one which is
logging out. There is no need to use ABTS on these; they may simply be
cleared.
E 012 Page 20, Section 6.2
If all tasks from all initiators are to be aborted, reference should be
made to 7.1.2. This is a better description of using ABTS than is given
in this paragraph.
E 013 Page 25, Section 7.1.2, ABTS protocol
FCP requires the use of the ABTS-LS protocol, but it is not fully
described in any standards document. This really belongs in FC-PH, but
for now perhaps it would be appropriate as an Annex in FCP.
The following features are not currently specified in FC-PH but advocated
by FCSI-101 ("FCSI Common FC-PH Feature Sets Used in Multiple Profiles",
page 10): ABTS may be sent at any time by either side, regardless of
Sequence Initiative or Credit; rules for setting SEQ_ID and SEQ_CNT by
a port which has not yet sent a sequence in the Exchange to be aborted;
BA_ACC frame should set SEQ_CNT_LO to 0 and SET_CNT_HI to FFFF.
END OF FCP LETTER BALLOT COMMENTS
--
John Lohmeyer E-Mail: John.Lohmeyer at FtCollinsCO.NCR.COM
NCR Microelectronics Voice: 719-573-3362
1635 Aeroplaza Dr. Fax: 719-597-8225
Colo Spgs, CO 80916 SCSI BBS: 719-574-0424 300--14400 baud
More information about the T10
mailing list