P1394 Mail Archive: Re: P1394> Revised PWG1394 Cmd Set

P1394 Mail Archive: Re: P1394> Revised PWG1394 Cmd Set

Re: P1394> Revised PWG1394 Cmd Set

Fumio Nagasaka (fumiona@venus.dtinet.or.jp)
Thu, 23 Jul 1998 22:09:46 +0900 (JST)

Dear Greg,

1. Is a "command tag" same as a "transaction number" ?

2. Do you really believe a target device can fail to
receive an ack-packet?

3. I would like to suggest three commands listed below;

An initiator requests a target to stop ORB fetching,
and solicits the target to reply STATUS block when
the last ORB had been executed.

A target requests an initiator to stop appending new
ORBs on outstanding linked list. The initiator may
invoke "close" command when it received STATUS bock
associated with the last ORB.

A target request an initiator to release specified ORB
without completion STATUS block.

Fumio Nagasaka
>Grettings all,
>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
> - 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:
> 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.
> Closed direction inferred from queue_id bit.
> Valid on both queues. Invalid only in the
> UnOpened Connection state.
> Valid only on I2T data queue. Valid only
> in the Opened Connection state. Valid only
> while the queue is open.
> 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
> | All other cmds is ERROR ]
> _______________________|
> |
> | | | TRANSPORT_I2T_DATA is OK if
> | | | I2T direction is Open
> | | | TRANSPORT_T2I_DATA is OK if
> | | | T2I direction is Open
> _______________________| | |
> ||| | |
> ||+- TRANSPORT_CLOSE (I2T) + |
> || && T2I still open |
> || |
> |+-- TRANSPORT_CLOSE (T2I) --+
> | && I2T still open
> |
> | I2T & T2I closed TRANSPORT_CLOSE is OK
> +---> 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
> 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
> 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

Fumio Nagasaka
EPSON Software Deveopment Lab., Inc.
voice: +81 268 25-4111