Subject: P1394> Re: Device discovery on 1394

From: Danny Mitchell <[email-masked]>
Date: Tue, 17 Jun 1997 04:10:28 -0500

Peter,

I believe the problem I am seeing is the easy determination of what type of
devices are out there.  For example in current os's a generic monitor
driver can be loaded just by knowing an unknown device is a monitor.  For a
printer or other generic device ( like a camera complying with the sony
desktop camera specification ) could be loaded.  In the case of a low-end
digital camera,  the camera would like to be able to assess that a printer
is out there that would support the "Digital Still Image" protocol with
very little overhead.  

This is where the PWG(s) are coming from.

Unless you are stating that the >From: [email-masked]
>Date: Fri, 13 Jun 1997 13:47:41 -0400 (EDT)
>To: [email-masked]
>Subject: Re: Device discovery on 1394
>
>In a message dated 97-06-13 07:22:56 EDT, [email-masked] (Danny Mitchell)
>writes:
>
><< Even if we decide to use an SBP2 transport protocol there is no method for
> device discovery.  This begins to push us to an FCP like protocol which at
> least has defined methods for device discovery.
>  >>
>
>I believe that there is an education problem here, not a lack of "defined
>methods for discovery" in SBP-2.
>
>The method is simple: the initiator examines configuration ROM for a unit
>directory with a Unit_Spec_ID of 0x00609e and a Unit_SW_Version of 0x010483.
>At this point the initiator knows it has discovered an SBP-2 device. What
>kind of device is it looking for? A printer? A disk that uses the SCSI
>command set? A still image camera? An Internet capable node? At this point,
>in the same unit directory, it takes a look at Command_Set_Spec_ID and
>Command_Set to find the desired match.
>
>To make this example a little more concrete, if the PWG invented a new
>command set that is unlike things that have existed in the past, the PWG (or
>whatever standards body becomes responsible for the care and feeding and
>future extensions to your standard) would acquire a 24-bit "company" ID from
>the IEEE and then pick a number to mean "PWG printer command set." These
>numbers would be Command_Set_Spec_ID and Command_Set.
>
>FCP operates along fundamentally similar lines: the searcher (initiator)
>examines configuration ROM looking for a unit directory that declares itself
>to be FCP.
>
>FCP also has a broadcast "Is anyone there?" feature. I think I can safely
>speak for quite a few in the 1394 community who believe that broadcast is not
>as attractive as it might appear---particularly if the volume becomes higher.
>Among broadcast's problems are a) required fixed address offsets to receive
>the broadcast, b) FIFO overflow problems in devices that have to receive the
>broadcast to determine that they're not interested, c) probable poor use of
>"global" broadcast in a bridged environment and d) lack of confirmation (did
>you fail to get an answer to your "Are you there query?" because no one was
>there or because the broadcast was discarded by a target whose FIFO was
>full?).
>
>Please feel free to recirculate this with the PWG.
>
>Regards,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>[email-masked]
>
>
>
Regards,  Danny Mitchell  ( Dallas, Tx )

 BuS Solutions SW Manager ( 1394, USB )
 Ph: 972-480-3411     www.ti.com/sc/USB 
 Fx: 972-480-3160     www.ti.com/sc/1394
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243

---

From: "Atsushi Nakamura" <[email-masked]>
Date: Wed, 18 Jun 1997 00:16:14 +0900

Some comments regarding this issue,

> >examines configuration ROM looking for a unit directory that declares
itself

This is exactly the issue we want to solve;
Currently in the above example, there is no way to tell that a 
SCSI/SBP-2 device is not a disk, but maybe a printer.
There may also be an internet capable digital camera,video
camcorder,scanner......which one will it be?
As for the FCP example, the initiator will find a FCP device,
and furthur know that it supports the AV/C command set(for example),
but it will not discover it's actual function(printer,camera,stereo...)
unless the initiator supports that protocol and initiates communication
in AV/C over FCP, then inquiring.

The unit_directory definitions of current transport protocols
is defined in a way that the initiator will discover the characteristics 
of a node by it's protocol first, and then finding the actual device
function by "talking"in that protocol
It shows that the current ROM definitions support protocol(device)
discovery, but not function device discovery.

PWG/PWG-C's approach to the device discovery scheme
(not the printing protocol, they are separate because device discovery
is a scheme that applies to any device, not just printers.)
is to provide a common (protocol-free)"short-cut" to
discovering the "device",or functions FIRST, then the protocol
it supports.
It will not conflict with the existing ROM definitions (SBP-2,FCP),
but co-exist so that the initiator can choose discovery paths;
existing ROM definitions for protocol-first device discovery,
and the PWG/PWG-C path for function-first device discovery.

> This is where the PWG(s) are coming from.

I agree with Danny's opinion. 

Regards,

Atsushi Nakamura
BJ Printing Technology Development 22
Canon Inc.

+81-3-5482-8396 (tel)
+81-3-3756-6052 (fax)
[email-masked]

----------
> ·ol : Danny Mitchell <[email-masked]>
> ˆ¶æ : [email-masked]
> CC : [email-masked]; [email-masked]
> Œ–¼ : P1394> Re: Device discovery on 1394
> ‘—M“úŽž : 1997”N6ŒŽ17“ú 18:10
> 
> Peter,
>