I do not think it is necessary for the initiator to control connection
of each direction separately at transport level.
I suppose the initiator can do it by not issuing either
TRANSPORT_I2T_DATA or TRANSPORT_T2I_DATA command, while
uni-directional target may want to declare its capability.
Because we are providing bi-directional transport, I think, whether
clients use it as uni-directional or bi-directional is up to the
clients.
Any suggestions?
Akihiro Shimura
On Mon, 20 Jul 1998 10:05:11 -0700 (PDT)
Greg Shue <gregs@sdd.hp.com> wrote:
>
> 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
> 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
> ----------------------------------------------------------------
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging System Promotion Project CANON INC.