1394 PWG - Issue No.961206-001

• The main issue raised was SBP-2's support for True bi-directional communication. Some feel it is Bi-directional. Need better investigation into issues.

• Multiple Logical Channels
• Flow Control
• Multiple Hosts Connectivity
• Multiple Targets Connectibility
• Reconnection after bus reset

• 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.

• 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

• 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

• Not true bi-directional communication
• Bi-directional extensions complicated and troubled
• ORB fetching considered "heavy protocol"
• HPT is a Command set layer on top of SBP2 that adds the functionality of the required transport.

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

• 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

• 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

• 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.

• Only one type of the SBP-2 target agent is used
• Can executes a single request at a time
• Does not support target agents that can manage queues (linked lists) of requests.
• Creates a 1284.4 Management ORB—using a new function code—and its associated Status Block

• pure data link
• bus reset only affects a single data link transaction
• uses an existing standard

• (If there is no timeout on the completion of a single request process, is it possible to block the activity of another channel?)
• Explanation that one Login would be executed for each separate 1284.4 channel, enabling multiple ORBs per device.

• Support multiple, concurrent, independent, symmetrical connections – These requirements are achieved, but in order to provide "symmetrical connections," a set of both initiator and target SBP-2 capability code would have to be implemented at each endpoint. [Randy noted that these implementations must be well-specified as part of the standard. This would ensure that a commercially-supplied implementation (in an operating system) will work properly with the code developed by a device vendor.]
• Provide in-order, byte-stream and in-order, buffer (datagram?) services – Achieved.
• Provide a directory service – Achieved by 1284.4
• Transparently handle transient link interruptions – Achieved.
• Reliability – Achieved at transaction layer.
• Be data, application and O/S independent – ???
• Do not preclude concurrent operation of other protocol stacks – Achieved.
• Provide efficient data transmission – Achieved.

• X3T10 group proposed a Bi-D ORB which is double the size of a normal ORB.
• This would allow either reads or writes for a given Bi-D ORB in the task list.
• Other WG reflector traffic felt the same functionality could be accomplished with higher layer by just adding two ORBs to the list and allowing out of order execution.
• Based on the discussions on the 1394 PWG reflector and at this meeting, it was decided that the current requirements could be met without use of the Bi-D ORB.

• How to supporting a PostScript capability which obtains information from a printer device. By issuing a <control-t> to a printer, it will cause the device to return status information of an unknown length.

• To be used by the stack as a way of alerting the host that the target device needs attention.
• It was not clear how OS vendors would support such capability.

• One solution would be to solicit OS vendors to provide Initiator and target functionality.
• May be considered as "too heavy"
• It was not clear if OS vendors would support such capability.
• Issue raised as to whether an "initiator-only" proposal could support all the features required for 1284.4.
  • Requires login-less messaging scheme.
  • Note: 1284.3/.4 implements this requirement via a polling mechanism in the datalink.

• The initiator talks to the target
  • DL_Data.indication.from.initiator
  • The initiator informs the target when output data is ready
  • The target informs the initiator when fetch transaction has been completed.
  • The Target talks to the initiator
    • DL_Data.indication.from target
    • The target informs the initiator when the output is ready
    • The initiator informs the target when the write transaction has been completed.

• The initiator reads from the target
  • DL_Data.request.to.target
  • The initiator informs the target when input buffer is allocated
  • The target notifies the initiator when write transaction has been completed.
• The target reads from the initiator
  • DL_Data.request.to.initiator
  • The initiator informs the target when output data is ready
  • The target informs the initiator when read transaction has been completed.

• What has not been stated clearly is that a significant goal is to gain support from commercial OS vendors for an implementation of the protocol stack this group will define. As SBP-2 is already implemented in some of the OS for future release, there is a good incentive to use this as the basis for the 1394 PWG protocol stack. One thing we need to define is the implementation needs of our stack. If the features are not available, what is the effect on this proposal?

The ORB fetch agent should only pass completed buffers up to the next level. This ensures that partial buffers will not be passed, or that repeat buffers will not be sent, if there is a bus reset while data is getting transferred.

Need to understand how things should work under these types of events:

• How are the task lists effected by bus resets?
• What are the rules for Abort?
• Does this require a packet size negotiation between .4 and the DL?
• Part of this discussion comes back to "Are we looking at the correct transport (1284.4) or datalink (SBP-2) for our requirements?"

• We would like to maintain one Client interface.
• We cannot do anything about the 1394 Transaction layer interface.
• See the following diagram:

• General Document Issues
  • Name of document no longer includes word "profile" in title. Now called "IEEE 1394 High Speed Bus Imaging Device Communications Specification." Point was made to reconsider if there was a preference to have the word "profile" back in the title. The decision was deferred.
  • This version of the document excludes any reference to 1284.4, and is submitted as a different proposal to the previous version (rev 0.05)—not just an update. Based on the review results, the two proposals will either be maintained separately, or merged into one proposal.
  • PROCESS ISSUE: List of requested changes to the previous document had not been made. Some were put into the document, some were not, and some are no longer relevant. [There was a side discussion about the logistics that should be followed when revising a document for easy review at a subsequent meeting.]
• Specific Comments
  • 10.1 – The question about symmetry will be removed and replaced by a new definition of symmetrical based on the previous discussion results.
  • SCOPE: Bridging - 10.2 – This section may need to be revisited based on activity of the 1394 bridging group.
  • 11 – The comment of how the Symmetrical Connections requirement is met will be modified to address the new definition.

• Key Features
  • Transport-only Command Set
  • Extended Access Control Policy
  • Ordered Task Processing Model
    • Confirmed Buffer Transfers
    • Unsolicited Buffer Available indication
  • Built upon stable SBP-2 protocol
  • Does not preclude Function Discovery Mechanism
• Command Set
  • Send Data-in
  • Receive Data-out
  • Max buffer transfer sizes negotiated per direction
  • Reserved fields for future extensions
  • Buffers tagged as out-of-band in CDB
  • Target may "ping" the initiator
• Access Control Extensions
  • Policy mirrors Login behavior
  • Reservation keys exist for verification
  • Resumption timeout negotiated during Login
  • Resumption timer takes effect upon a failed reconnect
• Ordered Processing Model
  • Initiator manages sequencing of transfers
  • Target may abort the task set to avoid deadlock
  • Task completion notification required
  • Buffer Available indicated
    • synchronously with task completion
    • asynchronously with Unsolicited Status
• What's New?
  • Command Set and Unsolicited Status defined
  • Transient Link Interruption support specified
  • Task request processing …
  • Mechanism to verify initiator is alive specified
• Differences
  • IEEE 1284.4 transport protocol not required
  • Ambiguous Out-of –order model removed
  • Each service modeled as a separate Unit
• Proposal Supports
  • Multiple, Concurrent, Independent, Symmetrical Connections
  • In-order Byte- and Buffer-mode data delivery
  • Data, App, and O/S independent
  • Transient Link Interruptions
  • Data Tagging
• Proposal Lacks
  • Directory Service Support (but doesn't preclude it)
  • Connectionless Service
  • Multi-casting Service
  • Bus-independent Protocol
  • Fair Access Management
  • Selectable Quality of Service
• Pending Issues
  • How to provide a Directory Service
  • How to encode transport client command set in Unit Directory structure?
  • How to resolve issues w/ Microsoft's SBP-2 Login policy?
  • How does Plug-n-Play work with this proposal?

• The requirements list includes the term "symmetrical connections."
  • Defined as "either endpoint can open or close a connection." Confirmed that this means either side (any node) can initiate a transport-level connection.
  • Further discussion occurred with regard to whether we really require "top-to-bottom" symmetry (at all layers), or just to provide symmetry to the client.
    • The group decided that the requirement should be refined to say that symmetry is a MUST at the client level ("first-order symmetry"), but any symmetry at lower layers will only be a desirable feature—not essential.
    • QUESTION: Will one device implemented with "top-to-bottom" symmetry have any interoperability problems with a device that was only implemented with client-level symmetry.
    • QUESTION: How do the implementations detect each other's specific behaviors. The topic of addressing this detection/communication was deferred for later discussion.
  • Issue:
    • Is "top-to-bottom" symmetry an "ideal goal"?
    • Does each node require "top-to-bottom" symmetry?
    • The idea of defining "conformance levels" was raised, to allow different implementations to be initiators, targets, or both. However, this topic was deferred until later.

• 1394 Devices with SBP-2 should use SCSI device types
  • RBC-Direct Access Device type 0x00
  • Printer Device Type 0x02
  • CDVD Device type 0x05
  • Scanner Device type 0x06
  • RBC Device Type 0x0e
• MFP devices would have separate unit directories with separate devices (printer, scanner).
  • There was some discussion that a MFP device should be identified as a MFP device with some sub-functions. Conflict with the current "Imaging Device Specification" is that there is a difference between the definitions of functions and services. A function in FDS points to a Unit Directory. Multiple services provided by the function are logical units under the unit directory.
  • In the Microsoft proposal, each logical unit is identified by a single Unit Directory. Microsoft SBP-2 will only enumerate one Logical Unit per Unit Directory.
  • Open issue: Does the Microsoft implementation impose any restrictions or limitations on our requirements?

1. 1284.4 over SBP-2
   Implement IEEE P1284.4 (MLC) protocol on top of the native SBP-2 command set.
2. 1284.4 over DFA
   Implement the IEEE P1284.4 protocol on top of the Dual FIFO Architecture as described
3. DPP 0.71 (PWG-C)
   Direct Print Protocol as defined by the PWG-C, sub-working group 1
4. Native SBP-2 (single login)
   Data going both directions in one task list
5. SBP-2 Non-mirroring (dual login)
   Task list for each data direction – 2 logins from one side
6. SBP-2 mirroring (cross login)
   A task list for each side – one login per side. Target/Initiator functionality on each side.
7. IP1394
   IP datagrams over the 1394 bus.
8. HPT
   Prefetching ORBs, queing on device. SBP-2 with an unordered execution model.
9. AV/C
   PWG-C working sub-group 2. Uses FCP. Has extensions for asynchronous data delivery.
10. Anything on FCP
    FCP
11. 1284 Parallel Port Registers on 1394
    Mapping of Microsoft ECP register model (with EPP extensions) onto the 1394 CSR.

1. 1284.4 over DFA
   Implement the IEEE P1284.4 protocol on top of the Dual FIFO Architecture as described
2. Native SBP-2 (single login)
   Data going both directions in one task list
3. SBP-2 mirroring (cross login)
   A task list for each side – one login per side. Target/Initiator functionality on each side.
4. HPT
   Prefetching ORBs, queing on device. SBP-2 with an unordered execution model.

• "That we adopt Rev. 0.1D (SBP-2 Native) and it's variants as our primary Transport focus for this working group." Motion was seconded, tabled for discussion and review of the other possible solutions. Motion was modified to include some of the HPT design concepts as "possible variants"-in addition to single, cross, and dual logins. Change was made to the motion and it passed on a vote of 15 yes, 1 no, 1 abstain.