P1394 Mail Archive: Re: P1394> 1284.4 over SBP-2

P1394 Mail Archive: Re: P1394> 1284.4 over SBP-2

Re: P1394> 1284.4 over SBP-2

Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
Fri, 13 Feb 1998 00:05:04 +0900 (JST)

On Tue, 10 Feb 1998 19:21:19 -0800 (PST)
Greg Shue <gregs@sdd.hp.com> wrote:

> > I await your responses.
> OK, here we go...

OK, I'll follow...

> Larry Stein wrote:
> > At this point in time we have apparently narrowed our potential solutions
> > to the following:
> >
> > A- 1284.4 with SBP-2
> > B- New SBP-2 command set with SBP-2


> As I understood it, the ability for 'a peripheral to operate over
> various interfaces without requiring major architectural changes
> to the product' is provided by meeting the specified transport
> service requirements. As long as the transport requirements are
> met, no architectural changes are required of the product. Thus,
> the transport layers are all modular with respect to the product.

I agree. This was original intent of the HPT which Ueda-san and I
introduced from last June meeting.


> Given all of this, I am compelled to support option B.

Basically, I also support to consider option B, but it is still not
clear for me how the data transfer of each direction is done
independently within single login in SBP-2 only solution.

If target request data transfer by "Data Available" flag in certain
status block, initiator will subsequently append "SND data-in" ORB in
the current task list. It will be possible for the target to check if
there is a "SND data-in" ORB in the task list BEFORE the initiator
appends the "SND data-in" ORB. After finding there is no "SND data-in"
ORB, the target may issue another unsolicited status which indicates
"Data Available". By this status, the initiator may append one more
(total two) "SND data-in" ORB in the task list. After that, the
target will need to abort the excessive ORB.
Is this a way the SBP-2 only solution works?

I think that aborting tasks implies subsequent task retries, and may
not be efficient.
It seems natural to make two independent logins for each direction,
one for down-link and another for up-link by using the idea to map
them into logical units. Furthermore, by extending this to allow to
allocate up-link in reverse fashion (i.e., the target of down-link
makes a login to the initiator of down-link), the link between two
devices will become symmetric if both ends have both initiator and
target functionality.

Any suggestions?

 Akihiro Shimura (shimura@pure.cpdc.canon.co.jp)
 Office Imaging Products Development Center 3