Responses to FCP Rev 8 Proposal for Comment Resolution

Charles Monia, SHR3-2/W3, 237-6757 26-Apr-1994 1622 monia at
Tue Apr 26 13:20:53 PDT 1994

From: Charles Monia
      Digital Equipment Corporation

To: SCSI Committee

Subject: Responses to FCP Rev 8 Proposal for Comment Resolution

The following are my responses to the proposed resolution of comments received 
on FCP revision 8. My replies are bracketed by "============".

Begin response
  5  Edit References (Technical)      
  Section 2 Normative References, Delete reference to SCSI-2 Standard.
  It does not apply to this standard.  Only SAM applies.
  The SAM document is the standard which the FCP is architected to
  implement.  However, since its models are in large part compatible
  with SAM, are architecturally well understood, and complete those
  parts of the SCSI-3 document series which aren't yet available, it is
  a valid reference and will be retained.Portions referenced from SCSI-2
  include the format of REQUEST SENSE information and the use of certain
  link signaling conventions.
   I disagree with making SCSI-2 a normative reference.
  In matters such as autocontingent allegiance and queuing, SCSI-3
  behavior is different from what's specified for SCSI-2. If SCSI-2
  becomes a normative reference, whenever there's a conflict between
  these standards, implementors and vendors will feel free to pick and
  choose among SCSI-2 or SCSI-3 behaviors, freely interpreting the
  SCSI-2 standard to fit new interconnects and protocols.
  It was my understanding that the committee wanted to avoid this
  possibility by starting with a clean slate and explicitly adapting or
  incorporating SCSI-2 requirements as needed to fit new technologies.
  In my opinion, the proper way to address the issue of completeness or
  compatibility is by identifying and addressing specific problem areas
  in the context of SCSI-3.
  11 Service Interface (Technical)     
  Section 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.
  This appears to be the most appropriate location for the tutorial
  function that points to the appropriate documentation in FC-PH.
  The information is used in section 5.4.
  The rewording of the definition (Comment 9) should correct any
  I disagree with the proposed response.
  The tutorial material accompanying the definition is not appropriate
  for the glossary. Such explanatory text belongs elsewhere in the
  12 FCP I/O Operation
  Section 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. 
  The SAM defines an I/O Operation as an operation defined by an
  unlinked SCSI command, a series of linked SCSI commands, or a
  task management function.  Within FCP, the I/O operation takes
  on the additional meaning of those information unit transfers and
  other activities that are performed across the Fibre Channel
  to implement a SAM I/O Operation.  A SAM I/O Operation has
  beginning and end conditions that are time independent and
  interface independent.  An FCP I/O Operation has timing conditions
  that indicate commencement and completion of the operation.
  Charles Monia has discussed this with me, and we have agreed that
  the definition and specification are correct.  No change will be made. 
  I disagree with the proposed resolution.
  The second sentence in the FCP says:
  "This [the paraphrased definition from SAM] is equivalent to the FC-PH
  exchange created to carry the SCSI command service objects....".
  As I recall our conversation, I agreed with the notion of extending
  the definition in SAM to include such protocol-specific activities.
  However, contrary to your response above, the use of "equivalent" in
  the quoted sentence leads the reader to infer that the protocol
  activities required to perform such operations are the same as the
  operations themselves. You seem to be replacing the definition in SAM
  rather than extending it.
  35 FCP I/O Operation
  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.
  The term "task" refers only to the work created in a logical
  unit associated with a command or group of linked commands.
  The correct term for this is FCP I/O Operation.  No change is required.
  I disagree with the proposed resolution.
  The first sentence of paragraph 1 states:
  "An Application Client begins a FCP I/O operation when it provides to
  the FCP a request for a SCSI command service."
  Strictly speaking, the above sentence is correct. However, the sense
  of the above, as I read it, is that a FCP I/O operation is identical
  to a command or series of linked commands. The broader meaning of the
  term seems to get lost.
  57 Mandatory/Optional (Technical)
  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 FC 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.
  After considerable discussion, the SAM document has been
  modified to indicate clearly which functions are mandatory 
  for all protocols; which functions are mandatory for a
  protocol to define but optional for a SAM compliant device
  to implement; and which functions are optional for both
  a SAM compliant protocol and a SAM compliant device implementation.
  It is the intent of FCP to define how these functions are
  implemented, but allow them to be optional for compliance
  with FCP.  This also serves as a warning to software
  designers that compliant ports are allowed to not implement
  certain functions.  Software designers should use alternate
  mandatory mechanisms for generic drivers.  No change is
  required in these lines.
  65 Mandatory/Optional (Technical)
  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.  
  Command linking is a SAM option that is defined by FCP for compliance.
  Implementations are not required to support command linking for
  compliance with FCP. 
  69 Mandatory/Optional (Technical)
  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.
  Command linking is a SAM option that is defined by FCP for compliance.
  Implementations are not required to support command linking for
  compliance with FCP. 
  I disagree with the proposed resolution to the items listed above.
  As I read your response, you seem to be saying that it is permissible
  for compliant ports to arbitrarily decide what device functionality
  will or will not be supported. Where does one draw the line?
  If I follow this line of reasoning, it would also be permissible for a
  protocol to be defined such that a compliant port would not be
  required to support mandatory device behaviors.
  110     Address model (Technical)
  Clause 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.
  The text will be modified to indicate that other logical units can
  be identified only for those SCSI device models that define an
  address structure.
  The last sentence will be changed to read:
  "An example of a four-layer hierarchical address structure suitable
  for use by a SCSI RAID device model is given in Annex B."
  The material in the cited paragraph overlaps the requirements defined
  in SAM, rev 13, pp 35 (see the definition for "Base Device" and
  "Logical Unit 0"). 
  I suggest modifying the FCP paragraph to supplement the information in
  SAM, rather than duplicate it.
  113     Correct CLEAR ACA (Technical)
  Clause 7.1.2, page 24, CLEAR ACA, Delete the last two sentences. 
  This behavior has no business in FCP or in any other
  The sentences are changed to paraphrase SAM:
  "All subsequent ... resume execution" 
     is changed to:
  "When the task manager clears the auto contingent allegiance condition,
  any task within that task set may be completed subject to the rules
  for task management specified by SAM."
  I disagree with the proposed resolution.
  I believe the section should be revised to state that the specified
  protocol implements the CLEAR ACA task management function defined in
  SAM, omitting the paraphrasing. References to the ACA bit in the CDB
  control byte should be deleted.
  145a    SCSI-2 (Technical)
  Clause 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.
  a) It is assumed that this actually references 7.4.6.
     In the absence of any drafts of SPC, SCSI-2 is a valid and
     useful reference.  This is especially true, since SPC will be
     faithfully reflecting SCSI-2.  
  b) The sentence reflecting minimums will be removed.
  c) SAM has been modified to allow FCP_SNS_INFO only with
     Check Condition or Command Terminated Status.  The text
     will be modified to reflect this change.
  I disagree with the proposed response. 
  See reply to item 5.
  145b    FCP_SNS_INFO (Technical)
  In Clause 7.4.5 or related clauses, 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.
  FCP uses autosense.  No change is required.
  Does FCP require all target devices to support autosense?
  148     Addressing model (Technical)
  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.
  This annex has proven useful to many implementors.  Since it is
  informative and given as an example, it should not be removed.
  No change is required.
  The normative specification of a model like this will be
  contained in SCC.
  I disagree with the proposed response.
  The manner in which the logical unit number is encoded must not be
  protocol-specific. Encoding conventions are not appropriate for
  inclusion in FCP. I believe the annex should be deleted.
  Comments generated by IBM
  150     Dual port reset (Technical)
  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. The function should reset all other ports of a
  multiport device.
  Proposed Response:
  SAM does not presently specify the "Bus Device Reset Other Port"
  function.  I would assume that is a "Target Reset Other Port" function
  in SAM terms.  Since FCP is likely to have multi-port capability,
  either the FCP_CDB field or the FCP_DL field should be used to
  specify some identifier for the other port.  The identifier should
  probably be the 64-bit WWN for the port.
  Since the specification of this function is so incomplete in the
  defining documents, I would prefer to put this in either
  an informative annex or a later edition of the FCP.
  In my opinion, the dual-port features defined for SIP are not
  appropriate for protocols that hide the underlying port configuration
  from the ULP. If this is the case for FCP, then no changes are
End response
Charles Monia
Digital Equipment Corporation
334 South Street
Shrewsbury, MA 01545

Tel: (508)841-6757		Email: monia at
Fax: (508)841-6100

More information about the T10 mailing list