Subject: Re: P1394> units and logical units definition

From: "Eric Anderson" <[email-masked]>
Date: 16 Mar 98 11:07:42 -0800

Greg Shue writes:
> The SBP-2 proposal allows this to be modeled as:
>     1 unit with:
>       2 logins to the Print Job logical unit
>       N logins to the Printer Status logical unit
>       1 login  to the Printer control logical unit
> 
>   Similarly, since each of these services operate independently
>   of each other (and may be used by other protocol stacks), SBP-2
>   allows for them to be modeled as:
>     2 + N + 3 units with 1 logical unit each
>   or:
>     1 Print Job Unit Directory with 2 logical units (instances)
>     1 Device Status Unit Directory with N logical units (instances)
>     1 Device Control Unit Directory with 1 exclusive logical unit 
> 
> The current PWG proposal restricts the options to the last one.

Even if each of those models is allowed by SBP-2, I think
the first one (a single unit with multiple LUNs) is both more
in the spirit of SBP-2 and more in the spirit of 1394.  This
model allows a 1394 node to have any number of independent
printer units, which is good if you are a multi-function node
like a computer or a fancy printer.

The other model is difficult if you want to have multiple
independent units in a node, because there is no clear way
to match up which Device Status Unit Directory goes with which
Device Control Unit Directory, or Print Job Unit Directory.
Rev 0.1d of the profile doesn't show how to do this (or I
missed it...)

So at face value I would prefer the first model (above) over
the second.

--------------------------------------
Eric Anderson            [email-masked]
Apple Computer, Inc.      408-974-8187
--------------------------------------

---

From: Greg Shue <[email-masked]>
Date: Mon, 16 Mar 1998 11:41:47 -0800 (PST)

> Rev 0.1d of the profile doesn't show how to do this (or I

No, you didn't miss it.  It is not there.  This may be an issue.

> So at face value I would prefer the first model (above) over

The big problem with the first model is that you cannot have
multiple connections between device status applications and
device status services when the applications reside on the same
node.  This _requires_ that multiplexing be done somewhere in the
system.

Smaller problems include how to figure out which LUNs are
associated with which type of service.

(Note: I was really figuring that device control would just be
a password-protected access into device status.)

Suggestions?

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------

---

From: Atsushi_Nakamura <[email-masked]>
Date: Tue, 17 Mar 1998 10:30:07 +0900

Eric wrote ; 
> > Rev 0.1d of the profile doesn't show how to do this (or I
Greg wrote ; 
> No, you didn't miss it.  It is not there.  This may be an issue.

It is SORT of there....

This can be handled with FDS, the Function Discovery Service
discussed in p1212r, IF we want to match units up by (physycal)
function instances.
(although it is not the original intent of FDS..)
FDS is a ROM structure that acutally matches up an functional
physical instance with all of it's associated (unit) directories.
The problem is that there is no telling whether those multiple units
 have to be "activated" simultaneously in order to achieve a function,
or just "choices"(ex. "A function can either talk in SBP-2 or DPP").

Rev0.1d states the use of FDS, so it's SORT of there... 

Eric worte ; 

> in the spirit of SBP-2 and more in the spirit of 1394. 

I do not know if it is right or not, but this is a similar 
response I get from 1394-ers around me. 
I have a hard time explaining that a 1394 printer (will probably)
consist of 2 or more unit (directories).
Most people had imagined a printer with only 1 unit with 1 LUN.

Because there still is some talk about desires for mutiple
independent channels within 1 LUN even inside PWG, I think this 
matter is worth going back to, get in synch and confirming again. 
(We forgot to give examples the last time, I think Greg's examples in
the last few mails helped some people to get the idea, Thanks Greg.)

P.S.
On radical comment I got was, 
If the printer was going to consist of multiple LUNs anyway, 
why not go further and restrict 1 LUN to 1 direction only ?

-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Develpoment 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):[email-masked]
email(2):[email-masked]
-----------------------------------------

---

From: Greg Shue <[email-masked]>
Date: Mon, 16 Mar 1998 17:47:41 -0800 (PST)

> physical instance with all of it's associated (unit) directories.

The piece that is missing is if a node provides the services
of multiple printers (e.g. a PC being a bridge to all the non-1394
printers to which it is directly connected).  How do you know
that "printer status" L is associated with "printer parser" Q?

---

From: Atsushi_Nakamura <[email-masked]>
Date: Tue, 17 Mar 1998 13:22:06 +0900

> that "printer status" L is associated with "printer parser" Q?

Very true.This is why I said "SORT OF..."

> > (although it is not the original intent of FDS..)

I will emphasize that FDS's initial objective is  
device discovery(and U/I purposes),not to solve issues like these,
so the scope of FDS ends at "unit" level.

As you said, FDS does not solve"The piece that is missing" so 
I think some other mechanism is needed for a match up at the
LUN level.

> > > Rev 0.1d of the profile doesn't show how to do this (or I

The above statement did not say anything about LUNs, so I thought
that FDS can be utilized if a match up at the unit level is all 
that's needed (which apparently is not...I should of figured that
out myself.) 

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho