As I have thought about many of the issues and simplifications
discussed at the July PWG 1394 meeting, I have tried to create
an overview of the resulting command set. Before I start modifying
the Command Set proposal, I would like to hear any concerns you have
with the revisions. The overview follows. Please respond with
any feedback before Friday 7/24/98. I will try to have the
revised Command Set proposal ready by 8/5/98. (I cannot have
it ready a full 2 weeks before the August meeting.) Thank you
for your feedback.
PWG SBP-2-based Transport Command Set
7/20/98
With:
- the restrictions imposed by the Microsoft SBP-2 implementation
- the desire from Randy Turner (Sharp) for Open & Close commands
- the removal of Vendor-specific extension mechanisms
- the relabeling of commands with more descriptive names
the command set transforms into:
TRANSPORT_STATUS {GET_PARAMETER w/ all params tags}
Only valid on T2I data queue, only valid
when in an Unopened Connection state.
TRANSPORT_OPEN {SET PARAMETER LIST w/ all settable parameters}
Contains all "Negotiated" parameter values.
Only valid on I2T data queue, only valid
when in an Unopened Connection state.
TRANSPORT_CLOSE {SET PARAMETER LSIT w/ only Mode parameter}
Closed direction inferred from queue_id bit.
Valid on both queues. Invalid only in the
UnOpened Connection state.
TRANSPORT_I2T_DATA {FETCH_DATA}
Valid only on I2T data queue. Valid only
in the Opened Connection state. Valid only
while the queue is open.
TRANSPORT_T2I_DATA {STORE_DATA}
Valid only on T2I data queue. Valid only
in the Opened Connection state. Valid only
while the queue is open.
the Command Set Model of Use becomes:
Login event ----> UnOpened Conn [ TRANSPORT_STATUS is OK
| TRANSPORT_OPEN is OK
| All other cmds is ERROR ]
_______________________|
|
+-- TRANSPORT_OPEN -> Opened Conn [ TRANSPORT_STATUS is ERROR
| ^ ^ TRANSPORT_CLOSE is OK
| | | TRANSPORT_I2T_DATA is OK if
| | | I2T direction is Open
| | | TRANSPORT_T2I_DATA is OK if
| | | T2I direction is Open
| | | TRANSPORT_OPEN is ERROR
_______________________| | |
||| | |
||+- TRANSPORT_CLOSE (I2T) + |
|| && T2I still open |
|| |
|+-- TRANSPORT_CLOSE (T2I) --+
| && I2T still open
|
+- TRANSPORT_CLOSE -> Closed Conn [ TRANSPORT_STATUS is ERROR
| I2T & T2I closed TRANSPORT_CLOSE is OK
| TRANSPORT_I2T_DATA is ERROR
| TRANSPORT_T2I_DATA is ERROR
+---> Logout TRANSPORT_OPEN is ERROR
The variables associated with TRANSPORT_STATUS become:
A) MAX_TASK_SET_SIZE (16 bits unsigned int,
2 is minimum;
2^14-1 is maximum)
B) MAX_I2T_DATA_SIZE (31 bits unsigned int)
C) MAX_T2I_DATA_SIZE (31 bits unsigned int)
D) STREAM_COMPLETION ( 8 bits unsigned int)
E) CONNECTION_STATE ( 2 bits unsigned int
0 => I2T CLOSED, T2I CLOSED;
1 => I2T OPEN, T2I CLOSED;
2 => I2T CLOSED, T2I OPEN;
3 => I2T OPEN, T2I OPEN;)
The target needs to communicate the following specific events
to the initiator even in the case that no commands are queued.
- UNIT ATTENTION: logical unit was reset outside of this Login
- Target has closed a communication direction and will reject
further TRANSPORT_?2?_DATA commands for that direction.
When all directions are closed, then target is should
Logout ASAP. (The target shall only successfully execute
TRANSPORT_STATUS commands.)
Since an initiator can not leave a TRANSPORT_T2I_DATA command
enqueued when the T2I direction is closed, this data must be
communicated via the Unsolicited Status mechanism. Also, since
an Initiator may not even exist on the bus (due to a transient
link interruption) when either of these events happens, they
must be buffered.
Now, error recovery for when a target detects an ACK Timeout on a
Status FIFO write requires some special considerations. When
this condition happens the initiator and target may be
out-of-sync with each other, and the SBP-2 protocol does not
provide a mechanism for the initiator to determine that the
condition exists. The problem breaks down to two issues:
Initiator Detection:
Because this condition is expected to happen _extremely_
infrequently, it is expected that a Bus Reset mechanism
is a reasonable way of forcing the initiator to resynchronize
with the target.
Recovery:
To recover from this condition, the target needs to infer
whether or not the initiator received the completion notification(s).
If the initiator did, the target may release the resources
or take the appropriate action assocaited with the command(s).
If the initiator did not, the target must determine whether
or not the same command (sequence, and associated data) is
restored to the execution queue.
If the same sequence is not restored to the front of the
queue, then the target should ignore all previous commands
and re-execute them.
If the same sequence is restored, then the target need
not reprocess the entire command and data block. It
simply needs to know where it left off within the
transfers.
This makes it reasonable to employ a command tag, used to
uniquely identify each previously active command within the
implicilty aborted task set, and new commands which were not
in the previously active task set.
Unfortunately, SBP-2 requires targets to support the ABORT TASK
function, and the process described for aborting tasks causes
previously valid commands to be turned into Dummy ORBs. This
effectively removes the command tag from the ORB, so the
queue's Execution Agent no longer sees command tags as
sequential even if they were assigned sequentially.
It may be reasonable for a target to enforce seeing
sequential command tags in order to recover from this
situation. If the queue's Execution Agent completed
all commands in that queue with a status of "ABORTED -
UNEXPECTED COMMAND TAG VALUE", then the initiator has
a chance to recover from the situation. This also means
that an ABORT TASK function causes all successive commands
on the associated queue to be aborted without affecting
the other queue.
This brings us to the following policies:
A) A target shall enforce sequential command tag values.
B) Initial command tag values shall be established by the
first command placed on each queue.
C) ABORT TASK shall indirectly cause the rest of the
command queue to be aborted without affecting
the other command queue.
D) Initiators shall retire a command tag until
it receives a successful completion notification
for a following command on the associated queue.
Once that following successful notification has
been received, the command tag may be reused.
E) Targets shall invalidate a command tag when
the completion notification for the associated
ORB has been succesfully acknowledged.
These policies allow the target to use the algorithm below
to recover synchronization:
If the target is not in a missing status FIFO ACK error
recovery situation, it shall examine the command at the
head of the queue and:
process it if it is either the first command enqueued
on this queue since Login, or has a command tag immediately
following the one of the last successfully completed command.
otherwise, abort it.
If the target is in a missing status FIFO ACK error
recovery situation, it shall examine the command at the
head of the queue and:
If the command tag matches the one of the unacknowledged
command, it shall make sure the command is processed and
resend the completion notification.
Else if the command tag follows the one of the
unacknowledged command, it shall ASSUME the completion
notification was successfully received by the initiator
and that the ACK transmission was lost. The pending
command shall be implicilty acknowledged by the new
command, and completed by the target.
Else the target shall abort it.
-- Greg Shue Hewlett-Packard Company All-in-One Division gregs@sdd.hp.com ----------------------------------------------------------------