| DISCUSSIONS: |
- Device Discovery: This occurs under the following circumstances;
- When service is needed à discover your world
- If a service is in use and a bus reset occurs - re-validate your world
"Your world" is whatever the operational environment is that your device needs in order to
operate.
- For example: If a camera needs a printer to send a file to then the camera would only Discover
functional units that have a Unit ID class of "Printer".
- After the camera establishes a "connection" (to be defined) to a particular printer unit, if a
bus reset should occur then that camera would need to re-validate that the printer it was
connected to is still there and then determine how to handle any interruption of service.
- Hierarchy of Discovery:
This is the order in which discovery occurs. A device in search of a service need only look as far
as necessary in order to determine if that functional unit can satisfy its' needs.
- Function 1394.x
- Unit ID 0 Class Printer
- Unit ID 1 Class Scanner
- :
- Unit ID n Class MFP
- EOL
- Service 0 Protocol FCP, SPB-2, DL or TP
- Service 1 Protocol
- :
- Service n Protocol
- Device discovery will be implemented by using the CSR to indicate the following information.
This will create a simple linked list that can provide quick access to minimal implementations as
well as provide an extensible method to indicate more complex resources.
(See IEEE Std. 1212)
- Use Command_Set_Spec_ID entry to identify 1394.x family. This is a unique numeric value that will
indicate that this device supports part or all of this standard. The exact meaning of this is TBD.
(need IEEE/RAC number)
- Command_Set entry to indicate how to interpret the next layer of information:
- Use Command/Response using FCP or other defined
- Use read transactions to access a linked list (1394PWG)
- Command_Set_Revision for something
- Management_Agent entry to point to the linked list or the address of the command/response window.
- Update of issue from 6/23/97 Meeting in Nashua
- Device Discovery General
- Goal is to discover the device independent of a Protocol.
Should not need to know a specific protocol to enumerate imaging devices
on a 1394 bus.
- Terminology - Device (node) Discovery Requirements
- mfr. Model# of node
- 1394.x support
- unique ID (serial number, GUID)
- Unit (function) Discovery
- functional unit class (ex. printer)
- Low level Service Discovery
- availability of the lowest layer above the 1394 transaction layer - the datalink layer
- High-level Service Discovery
- command set, image format
- Root Dependent Directory approach vs. Unit Directory approach.
- Hierarchically the root describes all functions before searching Unit directories.
- Unit directories refer to I/O driver software (communication protocols) and FCP already
defines sub functions using FCP.
- The Root directory is a bus level concept if we want to add information at
the Root we should take it to the IEEE 1212 committee.
- The scope of this effort has a greater global impact on other devices.
- Could also accomplish device discovery with a New Unit Directory.
- What approach is architecturally consistent with how devices currently work?
- Need to write this up and submit it to the 1394 TA Architecture Working
Group and/or the 1212 committee (or the appropriate persons) in terms of
what we are attempting to accomplish and what is the best way to accomplish it.
- Status Retrieval at device discovery level.
- Consensus seemed to be that true status retrieval should be
at the protocol level. Do we need anything beyond the device
responds to 1394 reads of the config ROM so it must be alive?
This will probably not be part of p1394.X
- Update of issue from 8/4/97 Meeting in Redmond, WA
- Update of issue from 9/15/97 Meeting in Atlanta, GA
- Device Discovery -> Function Discovery
- ISSUE: "How do we find a printer in a multi-device topology?"
- We don't want to utilize a specific protocol just to find a function in a topology.
- Other proposals include:
- SDD - Self Describing Devices (Sony proposal before TA)
- We should define what we mean by "Independent" functions as used in the 'function_class' key.
- The 1394PWG will seed the initial function_class keys. The idea is the list will be extensible and maintained by the IEEE RAC. The initial list will include:
- printer
- scanner
- fax
- multi-function
- The 1394PWG will seed the initial function_class keys. The idea is the list will be extensible and maintained by the IEEE RAC. The initial list will include:
- printer
- scanner
- fax
- multi-function
- Motion made, Seconded and passed without objection to adopt the FDS Ver. 0.5 specification as the basis for Function Discovery for 1394 PWG. This will become Version 0.1 of the PWG1394 Function Discovery specification. This includes:
- New root entry for FDS support
- Point to directory of function descriptor.
- Configuration change flag
- Function_List definition and contents
- Function_Description definition and contents
- Open issues for fds05 include:
- Exact number of keys
- Exact format of keys and fields
- Driver info block
- Does a suitable global registry exist?
- Do we make the registry extensible?
- Do we make the registry bus dependent?
- Do we seed the registry with certain functional classes?
- NOTE: Plug and Play (Microsoft PnP spec for 1394) requires a separate unit directory for each function. This is different than the current implementation for SBP2 and AV/C protocols.
- Update of issue from October 27th Meeting in Boulder, CO
- Device Discovery -> Function Discovery
- Feedback on FDS from 1394 TA meeting.
- Dislike for concept of having a Function Directory pointing to a separate Function Description Directory.
- Recommendation that the Function Description Directory be referenced from the Unit Directory. (Note: this is possible without changing the FDS proposal)
- After discussion regarding the feedback received at the TA Architecture meeting, agreement reached that the suggested modification is acceptable.
- Following item was intended to help stimulate Configuration ROM discussion.
- Proposal for specific key values:
- 1212 keys include:
- 12 Unit_spec_id
- 13 Unit_sw_version
- 14 Unit_dependent_info
- 15 Unit_location
- 16 Unit_poll_mask
- SBP-2 keys include:
- 38 Command_set_spec_id
- 39 Command_set
- 3A Logical_unit_characteristics
- 3B Command_set_revision
- 3C Firmware_revision
- SBP-2 Unit Dependent keys include:
- 14 Logical_unit_number
- 54 Management_agent_offset
- D4 Logical_unit_directory
- To define a 1284.4 architecture, the group proposed to use the following SBP-2 key values:
- 38 Command_set_spec_id will be used to assign the IEEE RAC OUI value
- 39 Command_set will be used to define a RAC-assigned number for IEEE 1284.4
- 3B Command_set_revision will be used to define the revision of the 1284.4 stack
|
