1394 PWG - Issue No.970514-006

1394 PWG - Issue No.970514-006 Back to the Issues Page

ISSUE NO.:	970514-006	NAME:	What kind of functionality needs to be supported?	STATUS:	TBD
RESOLUTION:				DATE:	TBD
ORIGIN:	05/14/97 Meeting in San Diego
DESCRIPTION:	Recurring theme in early presentations. Reflects much of the brainstorming which lead to the list of PWG requirements.
DISCUSSIONS:	Some Basic Needs Service Discovery Device Discovery Management Bus Events Re-connection Bus Reset Printer control model Multiple protocols on a single node Protocol selection Direct Status Retrieval printer status (simple on/offline, error, PE�) Access Control lock status login Update of issue from 6/23/97 Meeting in Nashua Requirements for Printing Protocol Access Control (Login) Fair Access Does this provide a way to determine how many Logins does a node have * Issue: does the thin (FCP) protocol require Access Control? In order delivery of Data Flow Control Guaranteed Delivery Error Detection Correction/Recovery Multiple Independent (Logical) Channels (Is a single channel Bidirectional?) PDL, Application and OS Independent Standard will allow con-current operation of multiple Protocols Implementation Goals: Physical Interface Independent Extensible Low System Overhead Backwards Compatible CONCLUSIONS: If a form of SBP-2 works with a yet to be defined SBP-2 Printer Command Descriptor Block (PCDB) we may not have enough effort to submit a second PAR. Similarly 1284.4 over SBP-2 may not be a new standard, it could be a 1394 printing implementation guide or recommended practice document. Effort wraps up to: Discovery Thick - SBP-2 plus new Printer Command Descriptor Blocks. Data Formats Update of issue from 9/15/97 Meeting in Atlanta, GA Requirements for Printing Protocol Parallel Port Replacement Protocol 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 Summary of requirements for Thick Transport Protocol stack 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 Update of issue from October 27th Meeting in Boulder, CO Requirements for Printing Protocol System Interfaces Interoperability 1394 PWG profile should co-exist with other printing efforts. We are working with members of PWG-C to define FDS to enable function identification and protocol selection. Layering we choose must fit into existing systems. Much discussion of 1284.3 and 1284.4 yet there is not as clear picture of interfaces between these modules. Datalink Interface (typical - from 1284.3 / 1284.4) DL_Register DL_Indication (read) DL_Confirmation (write) DL_Error (link error) Discussion on requirements for Thick Transport Protocol stack Proposed requirements were categorized as either 1284.4 or datalink (DL) layers or No Comment recorded (NC): 1. Connection Oriented (1284.4) 2. Reliable (DL) Suggestion to add two additional (sub-)requirements: Detection Correction 3. Byte steam and Buffer interface to the application (DL) 4. Service Discovery (1284.4) Opinions that inclusion of a directory service as a "Must" was too strong - should only be a "Want" 5. Multiple Logical Channels (NC) 6. Bi-directional data transfer (NC) 7. Peer to Peer (NC) 8. Application independent (NC) Email between meetings expanded this requirement to "data, application and O/S independent" Issue was raised that agreement is needed on "the appropriate interfaces". Issue was raised that the upper and lower interfaces need to be well defined. Issue was raised that the term "data" needs to be clarified and made more specific. 9. Does not preclude concurrent operation of other protocol stacks (1284.4 & DL) 10. Transient link interruptions are transparent (DL) Wants: 1. Connectionless support It was suggested that this item be re-considered by the group because it is so difficult to implement. 2. Multi-casting It was suggested that this item be re-considered by the group because it is so difficult to implement. 3. Bus Independent transport It was suggested that this item be restated as "Link-independent transport layer." 4. Data Tagging (Out of Band) There was a question about the merit of this requirement. Is it really a "Want"? New Issues Efficient data transmission: Should be stated as a requirement to provide flow control. Update of issue from Dec. 97 meeting in Los Angeles, CA 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 Meaning: Multiple, concurrent - Allows for more than one connection at a time. Meaning: Independent - Activity on one connection has no effect on other connections. Meaning: Symmetrical - Either endpoint can open and close the connection, and send data. Meaning: 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 Meaning: In-order - Data is delivered to the receiving endpoint in the same order as it was presented by the sending endpoint. Meaning: 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. Meaning: 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. Is this required? Data is received in the same form (packet size) as it was sent. Record mode or Packet mode? Provide a directory service Meaning: 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. Connections by service name, not socket number. Keep this as a Must. Explain how it will be used. Services provided by a given device. Does the naming service come up before the Transport? Should there be a 1394 level directory service? This may be an issue for the TA. Transparently handle transient link interruptions Meaning: The transport stack shall handle transient link interruptions without affecting the endpoints. These link interruptions include: temporary cable disconnect, 1394 bus reset, Loop, and Power (link power- Device is powered off but phy is still active). 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? Do we need to require anything other than the intrinsic reliability of the underlying link? 1394 phy and transaction layers do provide CRC detection. Correction may occur with some error types. Resolved- The thick transport will not require any additional error detection and correction than that supplied by the lower layers of the stack. Wants: Connectionless support Meaning: A non-bounded communication path between two endpoints. Data may be sent without "opening" a connection. Ability to send data without opening a connection. Resolved- Move this to a MUST, but that it may be a parallel protocol to the connection based transport. Multi-casting Meaning: Simultaneously sending data from one endpoint to multiple endpoints. Does this need to be bidirectional? Does it need to be reliable? Client can send a packet to multiple endpoints, not broadcast. Make this a WANT for the connectionless transport. It may fall out of the addressing model for this type of transport. See if there is a good application for this. Bus Independent transport layer Meaning: The transport layer may be used on other busses. Data Tagging (Out of Band) Meaning: 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. Is this required? Similar to out-of-band data in 1284.4. How would this be implemented? Why would you want to do this? Revisit this at a later meeting. Provide endpoints with fair access to other endpoints Meaning: The transport will prevent endpoints from monopolizing the link and preventing other endpoints from access. Selectable quality of service Meaning: The ability to adjust various quality of service parameters, including: Isochronous delivery Priority Propagation Delay Rate of transfer (bandwidth) This needs to be discussed later to determine if there are issues here that need to be addressed. Internal Thick Transport Stack Requirements The following are the requirements the transport stack places on itself. Musts: Do not preclude concurrent operation of other protocol stacks Meaning: Devices may implement and use other protocol stacks concurrently with this transport stack. Efficient data transmission: Meaning: 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 Meaning: The transport layer may be used on other busses. Would like to make this independent of 1394. Reuse of existing protocols where possible Save time by reusing existing protocols, rather than inventing new ones. From March 2nd, 1998 Meeting in Austin, TX Requirements Update see file "protocol_requirments_11.pdf" on web site Update of issue from April 13th, 1999 Meeting in New Orleans, LA 1394 PWG Solution If we address all the open issues and action items listed in the minutes, are we done?
Back to the Top of the Page

Back to the Issues Page / Back to the Top of the Page

If you would like to contribute any input, contact Greg LeClair.
Last modified May.18.1999.