> E) CONNECTION_STATE ( 2 bits unsigned int
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 at 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 at sdd.hp.com> ----------------------------------------------------------------
>
--
Akihiro Shimura (shimura at pure.cpdc.canon.co.jp)
Office Imaging System Promotion Project
CANON INC.