P1394 Mail Archive: P1394> September Meeting Minutes

P1394> September Meeting Minutes

gregory leclair (gregory_leclair@erc.epson.com)
Tue, 23 Sep 97 09:40:56 PDT


Attached are the September meeting minutes. They have also been posted
to the PWG website on the documents page.


Greg LeClair


===============================================================


1394 Printer Working Group
Atlanta Meeting - 9/15 & 9/16

Attendees:
Don Wright Lexmark / PWG Chair
Greg LeClair Epson / 1394PWG/1212 Task Group Chair
Larry Stein Warp 9 / 1394PWG Secretary
Brian Batchelder HP / 1394 PWG Editor
Fumio Nagasaka Seiko Epson
Yoshinori Murakami Epson
Atsushi Nakamura Canon
Osamu Hirata Canon
Shigeru Ueda Canon
Akihiro Shimura Canon
Brian Nagy Kodak
Jerry Thrasher Lexmark
Greg Shue HP
Alan Berkema HP
Lee Farrell Canon
Randy Turner Sharp

Agenda

I. Introductions

II. Next meetings:
Boulder/Denver 10/27 & 10/28
Los Angeles 12/1 & 12/2
Hawaii (January - TBD)

III. Meeting Plan:
FDS
- Presentations
- Discussion
Transport
- Presentations
- Discussion
Documents
- Sub-working group(s) on 9/16 afternoon & 9/17 all
day

IV. How to bring closure and issue results
FDS proposal (PWG & PWG-C)
SBP-2 based printer definition (PWG)
FCP based printer definition (PWG-C)
IP/1394 based printer definition (TBD)

Meeting called to order at 8:38 by PWG chair Don Wright.
$42 per day meeting charge.

I. Introductions

II. Next meetings:
Boulder/Denver 10/27 & 10/28

Boulderado Hotel
2115 13th St.
Boulder, CO 80302
Ph. 303-442-4344
Reservations 1-800-433-4344
$104 standard
$114 Deluxe

The October meeting could not be moved because the meeting contracts
have already been completed.

Los Angeles 12/1 & 12/2

1998 Schedule:
Hawaii (January - TBD)
Jan 19-23 or 26-30

(Schedule proposal to be posted separately. - GL)

Don Wright asked Greg LeClair to approach 1394 TA Steering Committee
if future meetings could be arranged +/- 1 week to allow attendance by
members from PWG-C at both meetings.

1394PWG meeting started here.
Greg LeClair - Chair

III. Meeting Plan:

Ats Nakamura, Canon made presentation on the PWG-C.
PWG-C met in September. The FDS will be a PWG-C proposal to PWG. The
PWG-C expects to present the Direct Printing Proposal at the DSI
working group at the 1394TA. Target date for 1st draft is October.

III.A. FDS
- Presentations
- Discussion

Please refer to spec posted on the pwg web site: FDS05.PDF

"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)

Add key "mode_unit_id" to 1212 structure.

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 list will
be extensible and maintained by the IEEE RAC. The initial list will
include:
printer
scanner
fax
multi-function

Motion made by Larry Stein to adopt the FDS Ver. 0.5 specification as
the basis for Function Discovery for 1394PWG. 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

Seconded by Randy Turner, passed without objection.

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?

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.

End of day 1.

Day 2
Meeting called to order at 8:45AM

III.B Transport
- Presentations

III.B.1 Greg Shue -- Parallel Port Replacement Protocol
Requirements
Outline of services that are provided on a parallel port that may need
to be provided on a 1394 system. This may be used as a set of
requirements with which to measure transport protocol options.

Required services to emulate connectivity of the parallel port:
Connection Oriented
Access Control
Reliable
Guaranteed Data Delivery
Flow Control
Error Detection
Error Correction/Recovery
In Order Data Delivery
Service Discovery

Direct Print Protocol requirements as defined by PWG-C for thin layer:
(R is a requirement as determined by 1394PWG, W is a want)
R 1- Symmetrical Connection
Peer to peer start of connection
R 2- "Real Time" Processing
Unsolicited Status indication
R 3- Multi-channel
Independent channels for Command and Data, for example
W 4- Dynamic allocation of memory
Full usage of 1394 memory model
(not like FCP with fixed window location and size)
R 5- Flow control of Command
push
6- Flow control of data
R push
R pull
W ISO
R 7- Negotiation
memory allocation
data flow
other parameters
R 8- Packet Segmentation
R 9- Error Recovery
reconnect
timeout
Low priority items:
10- Compatibility with FCP/AVC
not a requirement to be FCP
11- Multilogin
multiple host
12- Multicast
host to multiple ports/devices

OSI(ish) Model for 1394PWG
APP
Session
Transport
peer to peer
full usage of memory bus model
Negotiable transfer sizes to maximize use of MTU (Maximum
Transfer Unit)
Flow Control
Negotiation
Service Discovery
Datalink
CSR interface at device specific location
Flow control
CSR access negotiation
Transient Connection Disruption Tolerance
Node update - routing to transport
Transaction
Read-Write lock
Phy


III.B.2 Fumio Nagasaka -- Epson
SBP2 Printing Model

Minimal requirements for PC Printing protocol
Multiple Logical Channels
Flow Control
Multiple Hosts Connectivity
Multiple Targets Connectibility
Reconnection after bus reset


Multiplexing to support multiple clients for the transport.

Implementation of multiple logical channels through SBP2
How many logins does one printing session require
1-Build MLC internally within one login
2-Requires multiple login as same number of logical
channel
3-Prioritize logins
Believe that #3, Prioritize logins, is the best solution
This will implement a Primary host login but allow for other hosts to
login. Additional hosts will login as Secondary priority hosts.
Latest Epson proposal is available on the PWG website.

III.B.3 Akihiro Shimura - Canon
HPT High Performance Transport
HPT is a Command set layer on top of SBP2 that adds the functionality
of the required transport.
Full duplex communication
Queuing model
Request based Flow Control
3 command, 2 status
data transfer
read request, requested read
direct status, direct status response
Primitive device control/status
4 command, 3 status
Acquire, Release, Abdicate device response
Basic device status
Logical Channel
2 command, 2 status
Open, Close channel

HPT Objectives
High performance with low overhead
Bi-directional data transport
Multiple service channels
Application independence
Backward compatibility with bus environment support
Self configurable (like 1284.4 open channel), no prior setup
required

Please review specification at
ftp://ftp.tokyoweb.or.jp/pwgc1394/pub/proposals/canon/HPT03E.pdf and
it is also available on the 1394 PWG web site.


III.B.4 Alan Berkema -- Hewlett-Packard
FCP or SBP2 versus Printing Protocol Requirements
SBP2
Not true bi-directional communication
Bi-directional extensions complicated and troubled
ORB fetching considered "heavy protocol"

FCP
No access control
Fixed communication address
Does not extend to multiple devices

Proposal DFA -- "Data FIFO Address Protocol"
Create an Inbound and Outbound Queue on each of the initiator and
target
Both sides push data into the peer's data fifo
Login and Login Response
Provides access control
Facilitates connection to multiple devices
Allows simple reconnection
Provides for unsolicited status
Limited Loginless status through query logins
Need data FIFO address exchange mechanism

Pros
Borrowed from IP1394
Sort of FCP like
Bi-direction communication
Efficient 1394 unified block write transactions
simple, easy to explain
command set independent
easily add higher layer protocols
Logins do not add that much weight to FCP
Extensible to multiple devices
cons
Does not take advantage of 1394 shared memory
Do packets need additional header info
Does not address flow control

Could use this as a datalink layer for a 1284.4 transport client.


III.B.5 Review of requirements for Thick Transport Protocol
stack (TP/DL/PHY)

Requirements:
1. Connection Oriented
Open and close and connection to a service.
A connection between two endpoints
A service is above the transport.
One connection cannot block another
2. Reliable
Data is received correctly and in order of transmission
3. Byte steam and Buffer interface to the application
4. Service Discovery
Provides directory of services available to the transport.
Provides query support
5. Multiple Logical Channels
Allows multiple and independent connections to a device or
between different devices
6. Bi-directional data transfer
7. Peer to Peer
Either end may open or close a connection
8. Application independent
9. Does not preclude concurrent operation of other protocol stacks
10. Transient link interruptions are transparent

Wants:
1. Connectionless support
2. Multi-casting
3. Bus Independent transport
4. Data Tagging (Out of Band)

Clarifications
Connections:
peer to peer (open/close/data) from either end
bi-directional
1:1 relationship between endpoints
Reliable


III.C Documents
- Sub-working group for FDS will meet on 9/17.
- See following comments from 9/17 meeting:


IV. How to bring closure and issue results
FDS proposal (PWG & PWG-C)
SBP-2 based printer definition (PWG)
FCP based printer definition (PWG-C)
IP/1394 based printer definition (TBD)

Discussion on above topics was raised by Greg LeClair. Don Wright
proposed that the discussion on requirements be formalized and each
proposal submitter explain if requirements were met by their proposal.

Plan accepted and reflected below in Action items.

V. Action Items
1. FDS sub-group to meet on 9/17 and begin revising FDS doc.
(Nakamura, Nagasaka, Murakami, Thrasher, LeClair)
2. Requirements doc to be published ASAP
(Shue, Batchelder)
3. Comparison of Proposals to Requirements doc to be published at
least 1 week prior to Boulder meeting for consideration by WG.
Comparison and updated proposals should be sent to Greg LeClair
for posting by 10/20.
(All proposal submitters)


Sub-working group meeting on FDS - 9/17.

Goal of meeting today:
Put document into public hands
- Items in questions that need addressing:
- Key value 18h - ConfigROM dynamic nature????
- Establish rule of usage - boundary conditions
- Configuration_state change -> Configuration register
- forcing it to Random number may preclude use by a
vendor as a '1 of n' configuration value
- Consider allocating space and recommending usage.
- Exact value is vendor dependent.

Nagasaka asked question if we really need FDS as it is defined
- Reason: existing mechanism - re-read ConfigROM
- GL this is non-deterministic,
- Configuration change identifier tells us if ROM is
changed
- Global point of view
- Config_Identifier is just for FDS or global for ConfigROM

Document Action Items:

Title suggestions
Terminology:
Greg will draft explanation for forward.
- Big picture List of function and Unit identifier
Greg will send Ats a list of terminology changes
- i.e. we used this - now should be this

Rewrite document to utilize same terminology as IEEE-1212
- Possibly add new terminology to identify new items (FUNCTION)
- Change Annex A to informative

Point out contentious issues in the Overview
- Issues TBD
- Past discussion history
- Issues addressed & resolution (Like SBP-2 spec)

Current issues:
- scope of configuration identifier (just FDS or entire config ROM )
- Scope is just FDS or entire Config ROM
- break value into fields to identify what has changed.
- Possibly other method, needs investigation.

- Function Class categorization
- How is it represented - pair of FUNCTION & UNIT IDENTIFIER
- Central RAC for all "FUNCTION CLASSES" (IEEE RAC? others)
- Value for UNIT IDENTIFIER
- Pointer to Unit directory or
- same as (which Key?) in the Unit directory to identify the "I/O
driver software"

- Annex A - Function Unit Info field
- Usage is TBD
- 1394 PWG is discussing content such as legacy PNP string.
- Feedback appreciated
- Will be made informative at this time.

Nagasaka raised issue of power management for multi-function unit
- Requires further discussion, decided it did not directly affect FDS
and further discussion was postponed.

Meeting closed.


Submitted by:
Larry Stein
Warp Nine Engineering
lstein@fapo.com
and
Greg LeClair
EPSON Imaging Technology Center
greg@erc.epson.com