Subject: RE: P1394> units and logical units definition

From: Hitoshi Sekine <[email-masked]>
Date: Tue, 7 Apr 1998 22:50:20 -0700

Hi,

I missed this discussion. I am not sure why you had the kind of requirement.
I have never seen that multiple Logical Units are required by a single
function or service. I couldn't find a reason why it is needed. What kind of
function needs to support multiple logical units?

Thanks,
Hitoshi

> -----Original Message-----
> From:	Atsushi_Nakamura [SMTP:[email-masked]]
> Sent:	Tuesday, March 17, 1998 5:18 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: P1394> units and logical units definition
> 
> 
> It would help to convince me (and probably others)
> that we are going the right way, 
> and that everybodyis in synch. if we can :
> 
> 1. Confirm that the current usage of SBP-2 unit(directory)s and 
>    LUNs are consistant with the idea ("with the spirit")of units
>    and LUNs defined in the SBP-2 spec. 
> 
> >Note that SBP-2's concept of a printer certainly does not match
> >well with our devices.  Disks are easily modeled.  Scanners are
> >fairly easily modeled.  Printers definitely are not.
> 
>    As Greg mentioned, printers are modeled differently(more complex)
>    from disks, and I think we are starting to define a new usage 
>    of SBP-2 units and LUNs in the current printer profile 0.1d that are 
>    different from other SBP-2 devices.
>    (where 1 (printer) function is comprised of multiple units
>     of the same transport protocol (PWG profile over SBP-2) within
>     1 node, and a combination of specific LUNs across these differnt
>     units need to work simultaneously to achieve the (printer) function.)
> 
>   Greg (Shue)'s explanation about an example of a printer model
>   by considering logical units as a service (the cuurent profile0.1d) made
>   sense within itself, but the question whether that usage is the 
>   intended usage or not has not been answered. There also is the issue
>   on how to match up the LUNs
> 
> Eric says;
> >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.  
> 
>   The above comment increased the magnitude of my concern.     
>   I think this is a question of how the SBP-2 people intended 
>   units and LUNs to be used, so confirmation with (or a comment from)
>   a SBP-2 expert would help.
> 
> 2. Confirm that the current usage of units(and LUNs) are consistant
>    and "in spirit" with 1394 and 1212 (and other protocols aside from 
>    SBP-2.)
>    Same as above, other protocols(such as AVC/FCP, DPP/Thin,
>    Conf.camera spec. ) achieve the functionality within one "1212"unit.
>    (Services are MUXed within the transport and above)      
>    The current profile will be the first of it's kind to achieve a 
>    functionality by using differnt LUNS across different "1212" units so
>    there is a possiblity that the 1394 PC printer may look "odd"
>    in the 1394 world.
> 
> 3. Confirm within PWG that this is the way to go.
>    As I mentioned, the discussion about desires for mutiple
>    independent channels within 1 LUN is still continuing, so I also agree
> with
>    Alan that this is still hazy.
> 
> 4. Lastly, 
> 
> >      I think a detailed picture matching services to Unit Directories to
> 
> >      LUNs might help.
> 
> I agree with this idea.
> Modelling a printer application may be out of the scope of the profile,
> but I think an example of a what a "basic" printer should look like 
> will help understanding (even within PWG to keep everyone in synch !)
> 
> 
> >      Would be nice, schedule could be tight.
> >      How about 3/19 at 4:00PM?
> >      
> I won't make this, but please go ahead if this schedule is reasonable
> for everyone else.
> I also apologize for not being able to contribute face-to face.
> 
> Ats
> 
> 
> 
> At 11:17 98/03/17 -0800, [email-masked] wrote:
> 
> > > I thought we had a pretty firm idea on the handling of logical units.
> >      
> >      From the discussion it still seems hazy to me.
> >      
> >      I think a detailed picture matching services to Unit Directories to
> 
> >      LUNs might help.
> >      
> > > Does this discussion require clarification of the current profile 
> > > document, for full understanding?
> >      
> >      Absolutely.
> >      
> > > Also, is there need for a teleconference on this or any other subject 
> > > prior to the next face-to-face meeting?
> >      
> >      Would be nice, schedule could be tight.
> >      How about 3/19 at 4:00PM?
> >      
> >      3/20 could be bad for folks in Japan.
> >      3/23 is due date for the next rev of the spec.
> >      
> > Randy
> > 
> 
> -----------------------------------------
> Atsushi Nakamura
> -----------------------------------------
> 
> BJ Technology Development 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]
> -----------------------------------------