1394PWG - Client Requirements for Our Thick Transport Stack
-----------------------------------------------------------
The following is a list of requirements the client places on the thick
transport stack. The requirements are split into two sections: musts and
wants. They are intentionally brief, with definitions of terms following
each requirement.
Musts
-----
* Support multiple, concurrent, independent, symmetrical connections
Multiple, concurrent - Allows for more than one connection at a time.
Independent - Activity on one connection has no effect on other
connections.
Symmetrical - Either endpoint can open and close the connection, and
send data.
Connection - well-bounded communication path between two endpoints.
The endpoints can be on the same device or on different
devices.
* Provide in-order, byte-stream and in-order, buffer (datagram?) services
In-order - Data is delivered to the receiving endpoint in the same
order as it was presented by the sending endpoint.
Byte-stream - Data is delivered as a stream of bytes. The stream of
bytes is not guaranteed to be delivered to the
receiving endpoint in the same form as it was
presented by the sending endpoint. For example, a
stream of 80 bytes of data may be presented as 4-20
byte buffers, but delivered as 2-40 byte buffers.
Buffer (datagram?) - Data is guaranteed to be delivered to the
receiving endpoint in the same form as it was
presented by the sending endpoint.
For example, if data is presented in a buffer of
30 bytes, it must be delivered in a buffer of 30
bytes. The transport stack may limit the size of
buffers. It does not have to support segmentation
and reassembly.
* Provide a directory service
Endpoints on a specific device may be referenced by their service name.
This allows connections to be opened without any knowledge of the
underlying layer's implementation of sockets, etc.
* Transparently handle transient link interruptions
The transport stack shall handle transient link interruptions without
affecting the endpoints. These link interruptions include: temporary
cable disconnect, 1394 bus reset, etc. Do we want to provide a service
to optionally notify clients when there is a link interruption?
* Reliability
What level of reliability is required by the clients?
Wants
-----
* Connectionless service
A non-bounded communication path between two endpoints. Data may be
sent without "opening" a connection.
* Multi-casting
Simultaneously sending data from one endpoint to multiple endpoints.
Does this need to be bidirectional? Does it need to be reliable?
* Data tagging
Data can be tagged as "special data" by the sending endpoint. The
transport will indicate to the receiving endpoint that the data is
tagged. This is also known as out-of-band data.
* Provide endpoints with fair access to other endpoints
The transport will prevent endpoints from monopolizing the link and
preventing other endpoints from access.
* Selectable quality of service
The ability to adjust various quality of service parameters, including:
Isochronous delivery
Priority
Propagation Delay
Rate of transfer (bandwidth)
Internal Thick Transport Stack Requirements
-------------------------------------------
The following are the requirements the transport stack places on itself.
Musts
-----
* Be data, application and O/S independent
The transport stack shall not put any requirements on the format of
the data, nor shall it interpret the data in any way. The transport
stack shall work with any application that correctly uses the
appropriate interfaces. The transport shall be implementable under
any operating system.
* Do not preclude concurrent operation of other protocol stacks
Devices may implement and use other protocol stacks concurrently with
this transport stack.
* Provide efficient data transmission
Prevent unnecessary bus traffic (e.g. retransmissions) by not
transferring data until that data can be handled by the receiving
device. Balance bus traffic with protocol overhead.
Wants
-----
* Bus-independent transport layer
The transport layer may be used on other busses.
* Reuse existing protocols
Save time by reusing existing protocols, rather than inventing new ones.
Brian Batchelder
Greg Shue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Batchelder | Hewlett-Packard | mailto:brianb at vcd.hp.com
Connectivity Futurist | 1115 SE 164th Ave. | Phone: (360) 212-4107
DeskJet Printers | Vancouver, WA 98684 | Fax: (360) 212-4227