Updated Responses to Comments about FCP, X3T10-204, Revision 1
Bob Snively
Bob.Snively at Eng.Sun.COM
Thu Apr 27 02:22:01 PDT 1995
Document X3T10/95-204, Revision 1
To: John Lohmeyer
Chairperson, X3T10
Symbios Logic Inc.
1635 Aeroplaza Drive
Colorado Springs, Colorado 80916
Subject: Proposed response to public review comments on FCP
The accompanying pages document the proposed response to those public
review comments received about the draft proposed American National Standard
entitled Fibre Channel Protocol for SCSI, document X3T10/993D, Revision 10,
dated November 28, 1994.
The comments are identified by letters indicating the reviewer and by numbers
identifying the comments from each reviewer. The first section is a table
summarizing the comments and the response to each comment. The second
section is the text of the original comment and a formal response to the
comment, with accompanying explanations and justifications.
Sincerely,
Robert N. Snively, technical editor
Sun Microsystems
Mail Stop MPK 12-204
2550 Garcia Ave.
Mountain View, CA 94043-1100
phone: 415-786-6694
e-mail: bob.snively at sun.com
-----------------------------------------------------------------------------
Response to Public Review Comments
1) Summary of responses:
The following table summarizes the public review comments received about the dpANS
Fibre Channel Protocol for SCSI, document X3T10/993D, Revision 10, dated
November 28, 1994.
Comment T/E Title of Comment Sections Proposed
Changed Resolution
HP 1 T Provide Task Management Response Many Accept
HP 2 T Target Reset effects PRLI Withdrawn
HP 3 E Clarify "Ambiguous Exchange" Rejected
IBM 1 E Section C.1, wording change C.1 Accept
IBM 2 E Section C.2, wording change C.2 Accept
IBM 3 E Section C.2, wording change C.2 Accept
IBM 4 E Section C, wording change C Accept
IBM 5 E Section C.2, wording change C.2 Accept
IBM 6 E Section C.2, wording change C.2 Accept
IBM 7 E Section C.2, wording change C.2 Accept
IBM 8 E Annex C, wording change C Accept
IBM 9 E Annex C, wording change C Accept
IBM 10 E Section C.3, wording change C.3 Accept
IBM 11 E Section C.3.2, wording change C.3.2 Accept
IBM 12 E Section C.3.2, wording change C.3.2 Accept
IBM 13 E Section C.3.2, wording change C.3.2 Accept
U 1 T In Order Delivery TBD Accept
LLNL1 E Comment on 2 2 Accepted
LLNL2 E Comment on 3.1 2 Partial
LLNL3 E Comment on 3.1.3 and 3.1.4 3.1.3/4 Accepted
LLNL4 E Comment on 3.1.15 3.1.1.5 Accepted
LLNL5 E Comment on 3.1.25 3.1.25 Accepted
LLNL6 T Comment on 4.2 7.4.4,.5 Partial
LLNL7 E Comment on 4.3 4.3 Accepted
LLNL8 E Comment on 5.1 5.1 Accepted
LLNL9 E Comment on 5.2, Table 6 5.2 Accepted
LLNL10 E Comment on 5.5.6 5.5.6 Accepted
LLNL11 E Comment on 5.5.11 5.5.11 Accepted
LLNL12 E Comment on 6.1 6.1 Accepted
LLNL13 E Comment on 6.2.2 - 6.2.4 6.2.2, .4 Accepted
LLNL14 E Comment on 6.2.5 6.2.5 Accepted
LLNL15 T Comment on 6.2.5 6.2.5 Accepted
LLNL16 E Comment on 6.2.6.9 and 6.2.9.10 6.2.6.9 Accepted
LLNL17 E Comment on 6.3 6.3 Accepted
LLNL18 T Comment on 6.3 6.3 Accepted
LLNL19 E Comment on 7.1.2.2 7.1.2.2 Accepted
LLNL20 E Comment on 7.4 Rejected
LLNL21 E Comment on C.2 C.2 Accepted
FSI 1 E Add FQXID Rejected
FSI 2 E FQXID Definition Rejected
FSI 3 E Definition of Ports Rejected
FSI 4 E Unsolicited Command Rejected
FSI 5 E Starting Exchange Rejected
FSI 6 E Linking Rejected
FSI 7 E Task Management TBD Accepted
FSI 8 E Task Management Accepted
DEC 1 E Section 3.1.5 3.1.5 Accepted
DEC 2 E Section 3.1.7 3.1.7 Accepted
DEC 3 E Section 3.1.9 3.1.9 Accepted
DEC 4 E Section 3.1.10 3.1.10 Accepted
DEC 5 E Section 3.1.12 Rejected
DEC 6 E Section 3.1.13 Rejected
DEC 7 E Section 3.1.15 3.1.15 Accepted
DEC 8 E Section 3.1.18 Rejected
DEC 9 E Section 3.1.20 3.1.20 Accepted
DEC 10 E Section 3.1.25 3.1.25 Accepted
DEC 11 T Definition of Tag 3.1.28 Partial
DEC 12 E Section 3.1.33 3.1.33 Partial
DEC 13 E Section 3.1.34 3.1.34 Accepted
DEC 14 T Table 2 Table 2 Accepted
DEC 15 T SAM Protocol Services Rejected
DEC 16 T SAM Protocol Specific Responses Rejected
DEC 17 T Asynchronous Event Reporting Rejected
EMX 1 T Annex A Extended Link Services X3T11
EMX 2 E Annex A Extended Link Services A.2 Accepted
EMX 3 E Annex A Extended Link Services A.2 Accepted
EMX 4 E Annex A Extended Link Services A.3 Accepted
EMX 5 E Section 6, PRLO/PRLI fields 6.2.6, .7 Accepted
EMX 6 I Annex A Extended Link Services Review
Text of public review comments and proposed response:
HP Section. Comments by Hewlett Packard, Kurt Chan
HP 1 (Technical) Provide Task Management Response
In the description of Task Management Functions on page 60 of the SCSI-3 Architecture
Model (SAM), service responses are required which indicate the status of the function:
- Function Complete
-Function Rejected
-Service Delivery or Target Failure
SAM requires that one of the above service responses be returned for every task management
function. However, FCP provides no means of providing that response. There are valid reasons
why such a response is needed for multi-initiator, class 3 environments in Fibre Channel
(examples provided upon request). It is inappropriate to rely on link layer acknowledgments
(on class 1 or class 2 ACKs) to provide this service.
Therefore we suggest the following changes be made to FCP to make it compliant with SAM,
and to provide a reliable, class of service-independent FC-4:
Table 5, Page 10
- Change T1 to: Command Request and Task Management Function
- Delete or Reserve T5. If this change is unacceptable for backwards compatibility, add a PRLI
login option which specifies whether T1 or T5 is used to perform task management (see next
page).
Table 6, Page 11
- Change I4 to: Command or Task Management Function Response.
7.1.2.2, Page 25
Change the first sentence to: "A task management function shall not be requested in the same
Exchange as a SCSI Command."
7.4.5, Page 33
Modify RSP_CODE = 00 and add codes 04 and 05 to table 20:
RSP_CODE Definition
00 No Failure or Task Management Function Complete
04 Task Management Function Not Supported
05 Task Management Function Failed
Insert the following text below table 20:
The task management function may or may not have been performed by the target if
RSP_CODE is returned or if no FCP_RSP is returned before the Exchange is aborted. Values
04 and 05 are not valid responses to SCSI commands.
B.1.9, page 53
Change the example to T1 instead of T5 and add the I4 response. Delete the last sentence of the
first paragraph.
T1/I4 as a PRLI Option:
If a PRLI option is preferred for backward compatibility, add the following:
- Add note to table 5, page 10: "Using T1 to transfer Task Management functions is only
allowable when enabled via PRLI."
- Add note to table 6, page 11: "Using I4 to transfer Task Management functions is only
allowable when enabled via PRLI."
- Add as PRLI bit 7, word 3 to table 8, page 17: "Task Management Request Response sent as
T1/I4." Add description of this PRLI option:
Setting this bit indicates a request for the SCSI Initiator to transmit Task Management
Functions using T1, and for the SCSI Target to respond to Task Management Functions using
I4.
The text then provides the behaviors selected if Word 3, Bit 7 is to be defined.
HP 1: Response to comment HP 1.
The comment is accepted. The PRLI option is not selected, so all implementations are required
to make use of the T1/I4 mechanism for transmitting Task Management Functions. No
modification to the PRLI text is required.
HP 2 (Technical) Target Reset effect on login parameters
Login parameters should be in the set of objects within a Target which are restored to
their default conditions upon receipt of Target Reset.
After review, HP has withdrawn this comment.
HP 3 (Technical) Clarify "Ambiguous Exchange"
The wording regarding "ambiguous exchanges" should be clarified by making error
recovery within FCP profile-specific. Various profiles are explicit and complete in
defining error recovery. The standard should only provide mechanisms by which the
appropriate level of error recovery for the application can be assured. The following
modifications should help clarify this.
Section 7.1.2.2
Attempts to define the term "ambiguous exchange" and the use of this concept to invoke
error recovery is confusing and overly complex. Replace the last two paragraphs of
TARGET RESET with:
The TARGET RESET is transmitted by the initiator (exchange originator) using a new
exchange. Additional FC-PH recovery may be necessary following TARGET RESET.
Section 7.1.2.2
Attempts to define the term "ambiguous exchange" and the use of this concept to invoke
error recovery is confusing and overly complex. Replace the last two paragraphs of
CLEAR TASK SET with:
The CLEAR TASK SET is transmitted by the initiator (exchange originator) using a new
exchange. Additional FC-PH recovery may be necessary following CLEAR TASK SET.
Section 7.1.2.2
Attempts to define the term "ambiguous exchange" and the use of this concept to invoke
error recovery is confusing and overly complex. Replace the second and third
paragraphs of ABORT TASK SET with:
The ABORT TASK SET is transmitted by the initiator (exchange originator) using a new
exchange. Additional FC-PH recovery may be necessary following ABORT TASK SET.
HP 3: Response to comment HP 3.
The comment is rejected. For the operation of these task management functions to be
sufficiently standard to operate correctly, the two ends of the link must each reset any
command which may be in an unknown (ambiguous) state. Alternatively, all
outstanding commands must always be aborted by the initiator.
IBM Section. Comments by IBM, George Penokie
IBM 1 (Editorial) Section C.1, wording change
Page 58, Section C.1 - The statement "based on the SCSI committee's RAID addressing
model" should read "based on the addressing model contained within the SCSI-3
Controller Commands Standard (X3T10/1047D)".
IBM 1: Response to comment IBM 1.
Accepted.
IBM 2 (Editorial) Section C.2, wording change
Page 58, Section C.2 - The section name should be changed to "Definition of SCSI-3
Controller Commands (SCC) addressing model".
IBM 2: Response to comment IBM 2.
Accepted.
IBM 3 (Editorial) Section C.2, wording change
Page 58, Section C.2 - In the first sentence the statement "RAID addressing model"
should be "SCC addressing model" and the statement "SCSI disk array (SDA)" should
be "SCSI-3 storage array". In the last sentence the statement "of an SDA logical unit,
all physical SCSI logical units, and volume logical units." should be "of an SCSI-3
storage array, all peripheral device logical unit numbers, and all volume set logical unit
numbers."
IBM 3: Response to comment IBM 3.
Accepted.
IBM 4 (Editorial) Section C, wording change
Rest of Annex C - All "SDA" should be changed to "SCSI-3 storage array".
IBM 4: Response to comment IBM 4.
Accepted.
IBM 5 (Editorial) Section C.2, wording change
Page 58, Section C.2, equations at end of page - The following should be changed as
indicated:
P = Peripheral device
V = Volume Set
B = SCSI bus within the SCSI-3 Storage Array
IBM 5: Response to comment IBM 5.
Accepted.
IBM 6 (Editorial) Section C.2, wording change
Page 58, Section C.2, last sentence on page - The statement "address of a Volume"
should be "address of a volume set".
IBM 6: Response to comment IBM 6.
Accepted.
IBM 7 (Editorial) Section C.2, wording change
Page 59, Section C.2, Table 44 - "Physical logical unit/SDA" should be "Peripheral
device logical unit/SCSI-3 storage array" and "Volume logical unit" should be "Volume
set logical unit."
IBM 7: Response to comment IBM 7.
Accepted.
IBM 8 (Editorial) Annex C, wording change
Rest of Annex C - All "RAID" should be changed to "SCSI-3 storage array".
IBM 8: Response to comment IBM 8.
Accepted.
IBM 9 (Editorial) Annex C, wording change
Rest of Annex C - All "physical device" should be changed to "peripheral device".
IBM 9: Response to comment IBM 9.
Accepted.
IBM 10 (Editorial) Section C.3, wording change
Page 59, Section C.3, first sentence - The statement "logical volumes" should be
"volume sets".
IBM 10: Response to comment IBM 10.
Accepted.
IBM 11 (Editorial) Section C.3.2, wording change
Page 60, Section C.3.2 - The title of this section should be "Addressing of volume set
logical unit: example".
IBM 11: Response to comment IBM 11.
Accepted.
IBM 12 (Editorial) Section C.3.2, wording change
Page 60, Section C.3.2, first and second sentence - The statement "more disk drive
Volumes. Volumes managed" should be "more volume sets. Volume sets managed".
IBM 12: Response to comment IBM 12.
Accepted.
IBM 13 (Editorial) Section C.3.2, wording change
Page 60 and 61, Section C.3.2 - The term "physical logical unit" should be "peripheral
device logical unit" contained within the body of the standard. If it remains it may
cause confusion.
IBM 13: Response to comment IBM 13.
Accepted.
Unisys Corporation Section, Comments by Jerry Witalka
U 1 (Technical) In Order Delivery
My current reading of the FCP specification requires all Initiators to support an
FCP_XFER_RDY DATA_RO field that specifies out of order data delivery (SAM
random buffer access). I believe this is an unacceptable burden for those Initiators that
are required to support unlimited scatter/gather operations. Our host software is
allowed to specify scatter gather boundaries of a single main storage word.
Theoretically, we could be given a single 10000 byte disk read request that could be
mapped to a 200 entry scatter/gather list specifying 200 different main storage buffer
locations. If we had to support out of order data delivery, it could take an unacceptable
amount of processing time to pore through the scatter/gather list and figure out where
the starting storage address is for this Data IU as opposed to always processing the
scatter/gather list sequentially.
Given this, I would like to request a change to FCP to allow an Initiator to require in
order data delivery (SAM sequential buffer access) for all data transfers. SIP has
effectively provided this functionality with the Enable Modify Data Pointer (EMDP) bit
in the Disconnect/Reconnect mode page. The definition of this bit in the SCSI-3
Primary Commands could be expanded to require the FCP_XFER_RDY DATA_RO
field specify in order data delivery or a new bit could be added to the Process Login
FCP Service parameter page to require in order data delivery.
U 1: Response to comment U 1.
The committee recommends that the use of the Enable Modify Data Pointer bit in the
Disconnect/Reconnect mode page be defined for FCP. Implementation of this bit will
not be made mandatory in FCP for the following reasons.
1) The architecture described in this comment does not make maximum use of parallel
access disk systems that may return data most efficiently out of order. As a result, the
performance of systems that require that all delivery of data be in order may suffer.
2) Class 2 and Class 3 data may be delivered out of order by some fabrics. The fabric
login process that requests in order delivery on a frame by frame basis is outside the definition
of FCP, but might be required for systems like those described.
Lawrence Livermore National Laboratories Section, Comments by Lansing Sloan
LLNL 001 (Editorial) Comment on 2
We believe FC-PH may be listed as a normative reference now (and deleted from clause
8).
LLNL 001: Response to comment LLNL 001.
Accepted. (Verify with editors).
LLNL 002 (Editorial) Comment on 3.1
Many of the definitions include the text "[SAM]". Some have "[FC- PH]" or "[FC-
AL]". Such text seems helpful but should the meanings should be explained, or the text
deleted. Many of the terms with "[SAM]" are also defined in SAM Revision 016,
though not necessarily in SAM's "definitions" clause 4.1.
LLNL 002: Response to comment LLNL 002.
Partial. Section 2 explains how the references are generated and does
not specify where in the referenced document the referenced information
is found. The editor will use ANSI standard references. Brackets are
acceptable to avoid the repetitive wording: "As specified by..." Section 3
will get an additional indication that some of these are definitions from
other documents collected here for the convenience of the reader.
LLNL 003 (Editorial) Comment on 3.1.3 and 3.1.4
The terms "autosence buffer pointer" and "autosense returned flag" have "[SAM]" in
their definitions in the FCP document but do not appear to be defined in SAM Revision
016. (Both appear in SAM 012 clause 9.1 but not in SAM 016 clause 6.3.)
LLNL 003: Response to comment LLNL 003.
Since they are not used in the FC-4 document either, they should be deleted. Accepted.
LLNL 004 (Editorial) Comment on 3.1.15
Since operation associators are 64 bits long, not 32, the FQXID with operation
associators is a 176-bit concatenation, not 112.
LLNL 004: Response to comment LLNL 004.
Accepted.
LLNL 005 (Editorial) Comment on 3.1.25
The terms "SCSI command service" has "[SAM]" in its definition in the FCP document
but does not appear to be defined in SAM Revision 016. (It is in SAM 012 clause 9.1
but not in SAM 016 clause 6.3, where it appears to have been replaced by "Execute
Command" or "Send SCSI Command protocol service".)
LLNL 005: Response to comment LLNL 005.
The proper term is Execute Command. FCP will be changed accordingly. Accepted. The
definition will have to be modified in a number of places in FCP.
LLNL 006 (Technical) Comment on 4.2, 4th paragraph, 2nd sentence
This sentence states that if an unusual condition has been detected then SCSI
REQUEST SENSE and FCP response information are returned. Is SCSI REQUEST
SENSE supposed to be returned even if Auto-sense is not specified? (If the answer is
yes, that should be made explicit in FCP, since it sort of contradicts SAM.)
Similarly, if FCP response information is supposed to be returned regardless of auto-
sense, that should be stated. (SAM presumably does not cover this.) Clauses 7.4, 7.4.5,
and/or 7.4.6 may be better places to clarify this.
LLNL 006: Response to comment LLNL 006.
Section 7.4.6 specifies that the proper FCP_SNS_INFO shall be presented when
the SCSI status byte of CHECK CONDITION or COMMAND TERMINATED is presented as
specified by SAM. It further indicates that FCP devices should always use autosense.
Three additional issues have been identified while working with Mr. Sloane to
resolve this problem.
1) There is no specification defining when FCP Response Information must be
provided. Section 7.4.5 will be modified to indicate that FCP Response Information
is provided when any of the RSP_CODE conditions are detected by the target.
2) There is a discrepancy in the definitions of the FCP_RSP_LEN field.
Section 7.4.4 will be modified to indicate that FCP allows a length of zero,
four, or eight when FCP Response Information is provided. Other lengths are
reserved for future standardization.
3) The document is not perfectly clear about whether or not the FCP_RSP_LEN
field is always provided, even if the FCP_RSP_LEN_VALID bit is set to zero.
The text of section 7.4.4 will be clarified to indicate that both length fields
are always present, whether or not they are valid.
LLNL 007 (Editorial) Comment on 4.3, 2nd paragraph, 2nd sentence
The sentence says that task management functions... are always... the only IU in a new
Exchange. According to 7.1.2.2, that's not true for "terminate task", which appears to
be done only in existing Exchanges. Consider appending ", except for Terminate Task"
to the end of the sentence.
LLNL 007: Response to comment LLNL 007.
Accepted.
LLNL 008 (Editorial) Comment on 5.1, 1st paragraph and Table 3
Please state clearly in the paragraph what the FCP_Port address identifiers are. Please
use words that clearly say "D_ID" and "S_ID" in table 3 are the identifiers. (The closest
words found in a quick scan are in the definitions of "target identifier" and "initiator
identifier".)
LLNL 008: Response to comment LLNL 008.
These abbreviations and definitions will be added to sections 3.1 and 3.2.
LLNL 009 (Editorial) Comment on 5.2, Table 6
In the last line of the Note (and before the Key), delete the comma after "I2". Also
delete "are usable to".
LLNL 009: Response to comment LLNL 009.
Accepted
LLNL 010 (Editorial) Comment on 5.5.6
Delete the "is" that precedes "identifies".
LLNL 010: Response to comment LLNL 010.
Accepted.
LLNL 011 (Editorial) Comment on 5.5.11, 2nd sentence
In "... Base Address is beginning address ...", insert "the" after "is".
LLNL 011: Response to comment LLNL 011.
Accepted.
LLNL 012 (Editorial) Comment on 6.1, second paragraph, second sentence
Change "separated processes" to "separate processes" following the third instance of
"logically".
LLNL 012: Response to comment LLNL 012.
Accepted.
LLNL 013 (Editorial) Comment on 6.2.2 through 6.2.4
Each of these has words "for each FC-4" that I think are inappropriate in FCP. Clause
6.2.4 has three instances of the phrase. The last paragraph before 6.1.1 certainly says
the parameters for the other FC-4's are outside the scope of FCP (properly). Probably
the five instances of "for each FC-4" should be replaced by "for FCP".
LLNL 013: Response to comment LLNL 013.
The intent was to indicate that a PRLI could be performed for more than one FC-4 at a
time. The best way to do this would be to indicate in 6.2 at the end of the first paragraph
that image pairs for more than one FC-4 can be included in each PRLI command. Then
the term "for each FC-4" could be entirely removed.
LLNL 014 (Editorial) Comment on 6.2.5, first sentence
Change "effects" to "affects."
LLNL 014: Response to comment LLNL 014.
Accepted.
LLNL 015 (Technical) Comment on 6.2.5, last paragraph, last sentence
Should "default" precede "PRLI" in: "... PRLI shall be present at the completion of
PLOGI"?
LLNL 015: Response to comment LLNL 015.
The intent of this phrase is to indicate that implicit PRLI, if implemented, is present at
the completion of PLOGI. The sentence will be changed to read:
If default PRLI information is complete enough so that N_Port login (PLOGI) is sufficient to
perform an implicit PRLI, then PLOGI shall establish the same reset state and Unit Attention
condition that would normally be established by PRLI.
LLNL 016 (Editorial) Comment on 6.2.6.9 and 6.2.6.10
In the first paragraph, fourth sentence, of each, a sentence starts with "If either the
originator or the responder do not...". Change "do" to "does" in each clause.
LLNL 016: Response to comment LLNL 016.
Accepted.
LLNL 017 (Editorial) Comment on 6.3
In the second and third paragraphs, change "No further communication under the
affected FC-4..." to "No further FCP communication...".
LLNL 017: Response to comment LLNL 017.
Accepted.
LLNL 018 (Technical) Comment on 6.3, next to last paragraph
The first sentence talks about "... the referenced process image...", and the other two
sentences talk about a "PA". However, the content of this paragraph seems equally
appropriate to communication between entities neither of which requires a PA. If so, the
paragraph should be rewritten so that it does not seem to apply only when PAs are used.
The best correction is unclear, but replacing "PA" with "image pair" may help.
LLNL 018: Response to comment LLNL 018.
The first case shall be changed to refer to "communication with an image that..."
The second case shall be changed to refer to "image.."
Accepted.
LLNL 019 (Editorial) Comment on 7.1.2.2, first paragraph
Replace the first sentence with something like: "Except for TERMINATE TASK, a Task
management function shall be transmitted by the initiator (Exchange Originator) using
a new Exchange. There is no response from the target for a Task Management
function."
LLNL 019: Response to comment LLNL 019.
Accepted.
LLNL 020 (Editorial) Comment on 7.4, first sentence
Insert "payload" after "IU" or in place of "IU".
LLNL 020: Response to comment LLNL 020.
IU is the correct term. Rejected.
LLNL 021 (Editorial) Comment on C.2
In the second line below Table 43, there should be one colon (not two) following
"Generalized Address."
LLNL 021: Response to comment LLNL 021.
Accepted.
FSI Consulting Services Section, Comments by Gary Stephens
FSI 1 (Editorial) Add FQXID
Page 2, 3.1.15 Add the term "(FQXID)" behind the term name to be consistent with
other places where the abbreviation appears behind the term.
FSI 1: Response to comment FSI 1.
Already contained in section 3.2, Abbreviations. The convention is, except for the
glossary and the abbreviations, that the abbreviation is enclosed in parentheses after the
defining words the first time the abbreviation is used in the text. Change is not needed.
FSI 2 (Editorial) FQXID definition
Page 2, 2.1.15 In the process of a full Fibre Channel exchange, both the S_ID and D_ID
fields may change. This optional function makes it difficult to specify a fixed name for
the FQXID as specified in option b). Add some text to the standard to explain the
migration of these values in a full Fibre Channel implementation. Such use is not
prohibited by the standard and therefore must be described and mapped to FCP
constructs.
FSI 2: Response to comment FSI 2.
The conventions relating the S_ID and D_ID to the originator's N_Port ID and the
responder's N_Port ID as a function of initiative are well defined by the referenced
documents. There are no other valid changes in S_ID/D_ID values within an FCP
Exchange. This change is not required.
FSI 3 (Editorial) Definition of ports
Page 4, 4. 1, paragraph 4, line 2. The phrase "by a pair of N_Ports"' to "by a pair of
FCP_Ports or a set of FCP_Ports using initial process associators". See comment 2.
General The term N_Port should be removed from the document except in the definition
of FCP_Port. The term N_Port does not include the definition of an NL_Port for FC-
AL. The definition of FCP_Port should include the NL_Port for FC-AL.
FSI 3: Response to comment FSI 3.
After reviewing the text, the meaning described above appears to be included correctly.
This change is not required.
FSI 4 (Editorial) Unsolicited Command
Page 5, Table 1. row 4 Remove the term Unsolicited in the FCP equivalent column. The
command service request can be used for either an unsolicited command (i.e., the first
one for a new task) and also for subsequent linked commands which are solicited by the
previous FCP_RESPONSE IU.
FSI 4: Response to comment FSI 4.
The term is correct as defined in FC-PH. The same category is used for both the first
command and subsequent linked commands. No change is required.
FSI 5 (Editorial) Starting Exchange
Page 5, 4.2, paragraph 2 line 1 Change "starts an exchange by sending" to "starts an
exchange for the first request by sending".
FSI 5: Response to comment FSI 5.
The statement appears to be correct. X_ID reassignment, which might appear to be an
exception, is actually included in this statement, since reassignment of the X_ID does
not terminate an exchange, but extends it under a different name. Command linking,
which might appear to be an exception, is actually not part of this statement, since this
indicates how an exchange begins. No change is required.
FSI 6 (Editorial) Linking
Page 5, 4.2, paragraph 2, line 3. Change "The FCP_CMND" to "The first FCP_CMND".
Each FCP_CMND does not start an exchange in the case of linking.
FSI 6: Response to comment FSI 6.
The reference is correct as stated. The FCP I/O Operation for linked commands starts
with the first command in the link and continues with subsequent commands. No change
is required.
FSI 7 (Editorial) Task Management
Page 7, Table 2 Must be updated to match SAM functions for task management along
with corresponding text additions.
FSI 7: Response to comment FSI 7.
Accepted. The task management definitions in SAM will be reviewed and any new
information or changes will be reflected if required in FCP.
FSI 8 (Editorial) Task Management
Page 10, 5.3, Table 5 Adjust the T1 IU to include confirmed task management.
FSI 8: Response to comment FSI 8.
Accepted, See HP 1
Digital Equipment Corporation Section, Comments by Charles Monia
DEC 1 (Editorial) Section 3.1.5
All text after the first sentence is explanatory material which
is outside the scope of the definition and should be deleted.
DEC 1: Response to comment DEC 1.
Accepted.
DEC 2(Editorial) Section 3.1.7
See comment 001.
DEC 2: Response to comment DEC 2.
Accepted.
DEC 3 (Editorial) Section 3.1.9
See comment 001
DEC 3: Response to comment DEC 3.
Accepted.
DEC 4 (Editorial) Section 3.1.10
See comment 001.
DEC 4: Response to comment DEC 4.
Accepted.
DEC 5 (Editorial) Section 3.1.12
See comment 001.
DEC 5: Response to comment DEC 5.
This section summarizes the definition of a very bulky section of FC-PH. This
information is important to an understanding of the choices and definitions made in
FCP, so I recommend that it remain unchanged.
DEC 6 (Editorial) Section 3.1.13
See comment 001.
DEC 6: Response to comment DEC 6.
This clarification is an appropriate part of the definition because it relates SCSI and
FC-PH concepts, so I recommend it remain unchanged.
DEC 7 (Editorial) Section 3.1.15
See comment 001
DEC 7: Response to comment DEC 1.
Accepted.
DEC 8 (Editorial) Section 3.1.18
See comment 001.
DEC 8: Response to comment DEC 8.
This clarification is an appropriate part of the definition because it relates SCSI and
FC-PH concepts, so I recommend it remain unchanged.
DEC 9 (Editorial) Section 3.1.20
See comment 001.
DEC 9: Response to comment DEC 9.
Accepted.
DEC 10 (Editorial) Section 3.1.25
See comment 001.
DEC 10: Response to comment DEC 10.
Accepted
DEC 11 (Technical) Definition of tag
Section 3.1.28
The definition for "tag" in the first sentence should be changed
to: "The initiator-specified component of the task identifier."
All text following the first sentence should be deleted.
DEC 11: Response to comment DEC 11.
The first sentence should be changed as requested to match up with SAM. The
clarifying sentence beyond that is an appropriate part of the definition because it relates
SCSI and FC-PH concepts, so I recommend it remain unchanged.
DEC 12 (Editorial) Section 3.1.33
See comment 001.
DEC 12: Response to comment DEC 12.
The second sentence only will be deleted. The third sentence is an appropriate part of
the definition because it relates SCSI and FC-PH concepts, so I recommend it remain
unchanged.
DEC 13 (Editorial) Section 3.1.34
See comment 001.
DEC 13: Response to comment DEC 13.
Accepted
DEC 14 (Technical) Table 2
The names in parentheses in column 1 appear to be the names of
SIP messages corresponding to the specified task management
functions. These names should be deleted.
DEC 14: Response to comment DEC 14.
Accepted.
DEC 15 (Technical) SAM Protocol Services
In clauses 6.3 and 7.7 of SAM, protocol services to be provided
by an LLP are defined that support the command and task
management functions. The FCP protocol description should
reference the service and it's arguments by name. I would expect
to see a clause in FCP for each applicable SAM task management
or command protocol service. In addition to showing the service
interface and its parameters, the clause should map each SAM
parameter into its FCP-equivalent and describe corresponding FCP
behavior.
DEC 15: Response to comment DEC 15.
This is not really a technical comment, but an editorial. The functionality required by
SAM is included in FCP, but is not organized to explicitly relate the required services to
the FCP implementation of those services. In some cases using Class 3 services and
certain profiles, the SAM service is provided through a "Negative Acknowledgment".
In those cases the proper behaviors are assumed until a time-out or other error
indication indicates that the behavior was not complete. The FCP should not be
rewritten to match the SAM format until FCP-2 is published.
DEC 16 (Technical) SAM Protocol Specific Responses
As required by clauses 6 and 7 of SAM, FCP should identify the
protocol-specific responses corresponding to the following
service responses:
Task Complete, Linked Command Complete, Linked Command Complete
(with flag), Service Delivery or Target Failure, Function
Complete.
DEC 16: Response to comment DEC 16.
This is not really a technical comment, but an editorial. The functions required by SAM
are described by FCP, but not organized to explicitly relate the SAM responses to the
FCP implementation of those responses. In particular, the Task Complete information is
provided by the FCP_RSP. Linked Command Complete is provided by the same
FCP_RSP indication as task complete, but with different IUs. Linked Command
Complete with Flag is distinguished from Linked Command Complete by state
information retained by the host adapter. While these editorial changes would be nice,
the FCP should not be rewritten to match the SAM format until FCP-2 is published.
DEC 17 (Technical) Asynchronous Event Reporting
The mechanism for Asynchronous Event Reporting is not defined as
required by clause 6.6.4.1 of SAM.
DEC 17: Response to comment DEC 17.
Asynchronous Event Reporting is defined as a SEND command from a device that
normally acts as a target, but is temporarily acting as an initiator. This is explained at
the end of section 4.2. No changes are required.
Emulex Section, Comments by Greg Scherer
EMX 1 (Technical) Annex A (normative) Extended link services
Background for the comment:
In Annex A of FCP an FC-4 login/logout service is defined in order to
implement specific FCP functionality. This login/logout service is stated
to be generic and therefore designed to support multiple FC-4's within it's framework.
The login service (PRLI) supports FC-4 TYPE and or Process Associators to be
exchanged during login, in order to differentiate between separate FC-4 logins
(e.g. FCP, IPI, etc.), or even separate FC-4 image pairs (FCP image pair 1,
FCP image pair 2, etc.). This architecturally allows two N_PORT's with
independent FC-4's to communicate using independent FC-4 login parameters.
My issue comes from the fact that the logout service (PRLO) does not support
FC-4 TYPE specific logout. This means that if two N_PORT's choose not to use
Process Associators, (that will ensure image pair uniqueness), any PRLO (logout)
|from a single FC-4 will affect all others. Although today there may not be many
coexisting FC-4's that use PRLI/PRLO, I believe the intent in Annex A was to
document an enabling service that could be used in a much broader scope in the future.
Specific comment:
In Annex A the PRLO / ACC payloads define Parameter Page Word 0 Bit 31:16 as
RESERVED. This is the same field in the PRLI / ACC payload that is defined
as the FC-4 TYPE and TYPE code expansion. Without the TYPE and TYPE code
expansion area defined in the PRLO / ACC payload it is not possible (without
using Process Associators) to logout one FC-4 on a given N_PORT without
potentially affecting others.
Recommendation:
Add FC-4 TYPE and TYPE code expansion fields to the PRLO / ACC payloads, as
per the definition and field position of TYPE and TYPE code expansion fields
defined in the PRLI / ACC payloads.
In any case, tables 11 and 12 (PRLO / ACC payloads listed in section 6) must
be made to match tables 29 and 31 (from Annex A) as they currently contradict
each other regarding the definition of Parameter Page Word 0 Bit 31:16 (TYPE
and TYPE code expansion fields).
EMX 1: Response to comment EMX 1.
Since the actual standardization of this function is being carried forward
as an FC-PH-2 activity, this will ultimately be a comment against that document.
The editor will review FC-PH-2 for conformity and make those corrections that
are presently defined. This is a desirable characteristic which should be
carried forward.
The contradiction will be resolved. This comment is accepted in principle, but
requires supporting activities from another organization to be completed.
EMX 2 (Editorial) Annex A (normative) Extended link services
Page 39 first bullet:
- Word 0, Bit 14 Establish Image Pair
Should be bit 13 (as listed in table 24).
EMX 2: Response to comment EMX 2.
Accepted.
EMX 3 (Editorial) Annex A (normative) Extended link services
Page 41 fourth bullet:
- Word 0, Bit 14 Establish Image Pair
Image pair established only if bit 14.......
Should be bit 13 (as listed in table 26).
EMX 3: Response to comment EMX 3.
Accepted.
EMX 4 (Editorial) Annex A (normative) Extended link services
Table 31 entry 7 is 13-0 should be 7-0:
Item Word Bit
------------------------------------------------------------------
Logout parm response page 0-3 31- 0
Reserved 0 31-16
Originator PA Valid 0 15
Responder PA Valid 0 14
Reserved 0 13-12
Response code 0 11- 8
Reserved 0 13- 0 <------
EMX 4: Response to comment EMX 4.
Accepted.
EMX 5 (Editorial) Section 6 PRLO / PRLI Field definitions
Tables 8 and 10 document Parameter Page payload Word 0 bit 13 as
RESERVED. This same bit in tables 24 and 26 (of Annex A) is defined
as "Establish Image Pair" an "Image Pair Established" respectively.
The bit definitions in both sets of tables (8 / 24 and 10 / 26) and
text should match.
EMX 5: Response to comment EMX 5.
Accepted. Section 6 will be updated.
EMX 6 (Improvement) Annex A (normative) Extended link services
I would like to see more detail in the general description for PRLI
Parameter Page Word 0, bit 13 "Establish Image Pair". If this bit = 1
(Establish Image Pair and exchange parameters), must bits 15-14
(Process Associators) also be =1? There is no indication in the
text that they are tightly coupled, although I believe that they
are. Relationships such as these should be clearly defined (even
though potentially obvious).
EMX 6: Response to comment EMX 6.
This revision did not require Process Associators to establish an
image pair. When the PA is invalid, then the image is of the whole
node. This was kept vague so that either mechanism could be used.
The editor will review the text with respect to the latest revision
of FC-PH-2.
More information about the T10
mailing list