Discussion item warnings, FCP-2
Bob.Snively at EBay.Sun.COM
Fri Jul 9 13:47:13 PDT 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>
These will be included in T10/99-211r0 when it goes out later today, but
I thought a heads-up might be constructive. Note especially item 8.5, another
formal attack on process associators.
8.1 REC_TOV set/sense capability missing
At present, there is no mechanism to set or test the value of REC_TOV,
but there is a mechanism to modify RR_TOV. Since there are a number of
requirements that establish relationships among these values (for
example, RR_TOV must be at least 3 times REC_TOV), we must either fix
these values or provide a mechanism to detect and change them.
8.2 In-order delivery requirements
What fails if out-or-order fabrics are used? Can it be fixed? Is it a
small enough set of the recovery mechanisms that we should continue to
prohibit all out-of-order behavior, or do most of the mechanisms work
correctly even with out-of-order delivery?
8.3 Is the discovery table any help?
What else should be included in the table? See FCP-2, rev 02, section 4.6)
8.4 Behavior of PRLI
There is an implicit assumption in the choice of bits in the PRLI
request payload and in the PRLI accept payload that the PRLI request is
always performed by an initiator. Since devices can label themselves as
both and since there is no explicit rule that says the PRLI request is
always done to a device that is only a target, I assume that the bits
useful for initiators should be placed in both the PRLI request and the
PRLI accept payload.
The following bits were copied over from table 9 to be placed in
section 6.2.7, table 10.
Confirmed Completion Allowed
Data Overlay Allowed
I have not yet adjusted the text to clearly identify the bits as being
sourced by initiators and not set by targets. The reason is that the
PRLI image creation capabilities seem to be somewhat at odds with the
informative and negotiative intent of the the capabilities bits in
FCP-2. This will be addressed as a separate issue in 8.10, which
proposes that process associators be made obsolete in FCP-2.
8.5 Obsolete process associator
There is an informal proposal for making process associators obsolete,
at least for FCP-2. I will be making that proposal formal for the next
FC and FCP-2 meetings.
Note that the Process Associator definitions do not create a consistent
architecture with SCSI and with PRLI. The problem is:
1) Process associators do not take part in the SCSI LUN or initiator
2) Process associators do not take part in separating CRN or exchange
3) The theoretical basis for process associators implies that
independent processes are operating in the host. However, reservation
protocols use as their primary parameter various initiator port
identifiers, implying that the independent processes are not independent
for at least that major part of the SCSI behavior.
4) PRLI has some problems separating initiator/target capabilities by
process associator, since the process associator is not part of the
The best way to avoid having to figure out rational answers to all
these questions (which will inevitably violate other standards) is to
simply make them obsolete and not use them.
This is made more compelling by the fact that they are essentially
unusable with their present definitions.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10