Yes, there _does_ need to be a layer between 1284.4 and 1394.
This layer provides the functionality of _how_ 1284.4 sits on
top of 1394. Specifically, it implements the Data Link layer
required by 1284.4. This functionality is not directly provided
by 1394. It must address the issues of access control, dynamically
changing topology, transient link interruptions, packetized transfers,
actual data transfer scheduling for each direction. Not a trivial
piece of the puzzle.
> 3) I really don't like SBP-2. SBP-2 is an EXCELLENT model for existing
> storage devices. It is NOT a good model for peer to peer devices.
> Sure, the initiator/target model can be modified to have a target notify
> the initiator that data is available, but it is kludgy. Aborting the
> task queue is an exceptable solution if your model is primarily single
> direction data flow. But in a peer to peer environment, the data
> direction is going to switch a bunch. That is just not an exceptable
> design. Bottom line, you can make initiator/target model do peer to
> peer, but it won't do it well.
If the applications which run above the transport are not
peer-to-peer in and of themselves, then there is no NEED for the
transport to really be peer-to-peer (though it doesn't hurt).
> 4) DPP is not a transport layer. The Thin Protocol (defined in the DPP
> spec) that sits BELOW DPP is a transport layer. I like Thin Protocol.
> It's very lightweight. I don't think anybody could complain about
> adding the code to implement Thin Protocol. It doesn't provide multiple
> channels, but it does do segmentation/reassembly. It provides a very
> generic and simple "stream" transport.
DPP Rev 0.71 has two distinct parts: the DPP command set (which
lies above the transport), and the DPP transport stack (made up
of the "new" Thin Session, Thin Transaction, Isochronous, and
Asynchronous blocks).
I have just reread the DPP proposal, and it strikes me as equivalent
to SBP-2.
The Connect sequence exactly mirrors an SBP-2 login (w/ command-set
specific data).
The Disconnect sequence exactly mirrors SBP-2 logout.
The Reconnect sequence is similar to the SBP-2 reconnect sequence,
though it's not specified which end is supposed to attempt the
reconnect and what happens if both try it simultaneously. Also,
the reconnect window has been doubled from SBP-2.
The Thin protocol requires both nodes to make memory available to
the 1394 address space, instead of SBP-2's policy of initiator only.
The Thin protocol does explicit segmentation and reassembly.
SBP-2 does implicit segmentation and reassembly (it uses the
naturally available 1394 address ranges).
The Abort mechanism is provided by both.
Section 5.7.2 Command, clearly talks about a master/slave paradigm
in the two bullets spelling out the transfer sequences.
DPP is missing:
- flow control
- multiple logical channels
- info about how this fits into a Unit Architecture
- Actual command definitions
- error detection/reporting
It also requires devices to support at least a 12 quadlet block write
instead of an 8 quadlet block write.
> 5) I would be happy with IP/1394. It would allow us to have UDP and
> TCP transport layers that are already familiar to many. Unfortunately,
> I think this option is viewed by many to be "heavy", but it doesn't have
> to be. I don't care about DHCP, DNS, and other administrative
> protocols. I just want the transport layer (UDP/TCP). The real problem
> here is that it's going to take a long time until committees decide what
> IP/1394 is. If we are in a rush, this option isn't it.
>
> So, in summary, option 4 looks like the leader in my book. Options 2
> and 5 also have merit. That's my opinion. Anyone else?
I'll take SBP-2. It's better defined, available, and probably equivalent.
> Stephen Holmstead
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------