FCP Abort Agreement

[Kurt Chan]

| The way I look at it is as follows: In class 1 and 2,
| potentially hundreds of ABTS/LS operations do not need to be done if
| FCP remains unchaged. This is because a very large number of exchanges
| may exist but a very small number of sequences may be ambiguous at the
| target. (Please refer to FCP 8b for definition of ambiguous.)
| This situation occurs when the initiator has a very
| large number of commands (open exchanges) at the target but the target
| only has a single ambiguous exchange. (e.g. one of the exchanges has
| an unacknowledged frame but all the rest of the exchanges are
| quiescient--the target has acknowledged the command but is accessing
| the data.)

I agree with Giles on this point.  There are interlock points where
one side owns Sequence Initiative and the other side knows it owns it.
If a Task Management flag is received (or a Unit Attention condition
established) at these points, no Recovery Abort is needed.  In class
3, three out of the 7 possible Sequence launch points fall into this
category as noted by my previous memo. 

This is a SEPARATE issue from whether or not Targets are required to
initiate ABTS for all the other cases where the Exchange is "ambiguous".

| There is another solution which may pertain more to class 3 but could
| also be used: The initiator may wait RA_TOV before reusing any of the
| XID's.
|
| This may be the only reliable method for class 3 anyway.

Not true.  Class 3 local loops or fabrics which cannot delay frames do
not require the N_Ports to wait R_A_TOV - the behavior is identical to
class 1 in such cases.  FCP should not rule out optimizations for
these topologies.

Regards,
Kurt