IEEE P1284.4 draft standard for data delivery and logical channels for IEEE std. 1284 interfaces.Draft D4.00.1999

IEEE P1284.4

Draft Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces

Draft D4.00

December 1, 1999

Sponsor

Microprocessor and Microcomputer Standards Committee of the IEEE Computer Society

Prepared by the IEEE P1284.4 Working Group of the Microprocessor and Microcomputer Standards Committee

Copyright ©1996 - 1999 by the Institute of Electrical and Electronic Engineers, Inc. 345 East 47th Street

New York, NY 10017, USA All rights reserved.

This is an IEEE Standards Project, subject to change. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities, including balloting and coordination. If this document is to be submitted to ISO or IEC, notification shall be given to the IEEE Copyrights Administrator. Permission is also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position. Other entities seeking permission to reproduce portions of this document for these and other uses must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk.

IEEE Standards Department

Copyright and Permissions

445 Hoes Lane, PO Box 1331

Piscataway, NJ 08855-1331, USA

IEEE P1284.4, Draft D4.00, December 1, 1999

Draft Revision History

Revision	Date Issued	Description
4.00	December 1, 1999	∙	After BRC edits - Ready for delivery to IEEE
		∙ Change bars are relative to revision 3.00
3.93	November 29, 1999	∙	Created during BRC review process
3.92
3.91
3.90	November 27, 1999	∙	Editor’s proposed revisions as per ballot review and other
			comments
3.00	August 12, 1999	∙	General cleanup
		∙ Changed initial revision from 0x10 to 0x20
		∙ Eliminated vendor specific transactions (0x50-0x6F). Now
			reserved.
		∙ Added "NextSocketID" parameter to
			GetServiceNameReply to increase efficiency of service
			enumeration.
		∙ Defined operation when maximum packet sizes indicate no
			data can be transferred:
			∙ Max packet size = 0: No packets will be transferred in
			that direction
			∙ Max packet size = 6: Packets with zero-length payload
			may be transferred in that direction
		∙ New URL for Winsock-2 API specification
		∙ Removed AsyncSelect from sample API
		∙ Added Init back-off strategy and service enumeration to
			Implementation Issues Annex
2.00	April 5, 1999	∙	(Change bars indicate changes from 1.7)
		∙ Added end-of-message flag
		∙ Added section title to all section references
		∙	Added AsyncSelect
		∙ Added description of error conditions
		∙ Rearranged Transaction Channel flow control sections
		∙ Made API clause closer match to Winsock-2 API
		∙	General cleanups
1.80	May 13, 1998	∙	As reviewed in .4 review mtg. on May 12, 1998.
1.70	April 13, 1998	∙	(Change bars also indicate changes from 1.5 to 1.6)
		∙ Simplified by merging “address server” into “service
			discovery” and “CBT” into “1284.4”
		∙	Cleaned up text.
1.60	February 18, 1998	∙	From other changes noted but not made during the May
			1997 meeting.
1.50	August 12, 1997	∙	As reviewed and edited “on the fly” during the May 1997
			meeting.
1.40	May 12, 1997	∙	Updated to reflect changes from March/April 1997 meeting
			in Austin.
		∙ Most sections were reviewed and edited “on the fly” during
			the meeting. Sections 5.4, 5.5, 5.6, 7, 8 and the Annexes
			were not reviewed.
		∙	Updated SPI section.

ii

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

			IEEE P1284.4, Draft D4.00, December 1, 1999
	March 31, 1997		∙ Updated to reflect changes from February 1997 meeting in
1.30
			Orlando.
			∙ Renamed “command channel” to “transaction channel”.
			∙ Allowed multiple outstanding commands on the transaction
			channel.
			∙ Removed MLC annex.
			∙ Lots of editing for readability and better understanding.
1.20	February 24, 1997		∙ Updated to reflect changes from January 1997 meeting in
			Albuquerque.
			∙ ConfigSocket merged into OpenChannel
			∙ Combined CBT commands and replies into transactions
			∙ Moved address server to CBT commands
			∙ Command channel flow control made the same as all other
			channels
			∙ Added new flow control mechanism
1.10	January 3, 1997		∙ Update to reflect changes up to 5.6 per IEEE P1284.4
			meeting in New Orleans, 11-4 to 11-5 1996.
			∙ Cleaned up Error handling by adding replies to each
			command and clarifying use of the Error command.
			∙ Cleaned up footnotes to add normative info to the actual
			standard.
			∙ Added Init Revision negotiation
			∙ Revised and added crediting and flow control information.
			∙ Began error handling and FSM updates: categorized
			commands, updated tables.
			∙ Updated command and replies for clarification and errors.
1.00	October 30, 1996		Update to reflect changes covered through 5.4.1.1 per IEEE
			P1284.4 meeting in NY, 10-1-96.
			Added Service Discovery information based on approved
			proposals in clause 7 and Annex B.
			Converted all appropriate host/peripheral to primary/secondary
			peer terminology.
			Added CBT as name for IEEE 1284.4 transport.
			Added MLC© Legacy Issues to annex C.
			Continued cleanup and formatting to IEEE Standards Style
			Manual.
0.20	September 24, 1996		Incorporated HP’s MLC 3.8 specification technology for
			committee review.
			Incorporated data link requirements for committee review.
			Formatted & reworded as per committee review on 6/26/96
			Converted packet offsets to hex
			Forced reserved values to be 0x00.
			Began reformatting to IEEE standards.
0.01	June 26, 1996		Formatting Changes
0.00	May 21, 1996		Initial Version

iii

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

Introduction

(This introduction is not a part of IEEE P1284.4, Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces.)

This standard was formally started as an IEEE effort in January 1996. Members of the IEEE P1284.4 Working Group would like to thank the Hewlett-Packard Company, and the IEEE 1284.1 and 1284.3 committees for their efforts in establishing the foundation for this standard and allowing this committee to include their work as the basis for much of this standard.

At the time this standard was completed, the key contributors to the Working Group on "Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces" were as follows:

Larry A. Stein, Chair

Mark T. Edmead, Secretary	Brian Batchelder, Editor
Bob McComiskie, Secretary	Walt Scheiderich, Editor
Jim Anderson	Paul Lindemuth	Ron Talwalkar
Lee Farrell	Raymond Lutz	Randy Turner
Robert Gross	Mike Moldovan	William Wagner
Joe Halpern	Ron Norton	Andrew Warner
Reed Hinkel	Rick Pennington	Forrest D. Wright
Monte Johnson	Greg Shue	Atsushi Yuki
Laurie Lasslo	Lance Spaulding	Steve Zilles
Greg LeClair	Bill Stanley

Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. A patent holder (Hewlett-Packard Company) has filed a statement of assurance that it will grant licenses under these rights without compensation or under reasonable rates and nondiscriminatory, reasonable terms and conditions to all applicants desiring to obtain such licenses. The IEEE makes no representation as to the reasonableness of rates and/or terms and conditions of the license agreements offered by patent holders. Further information may be obtained from the IEEE Standards Department.

iv

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

			IEEE P1284.4, Draft D4.00, December 1, 1999
Contents
CLAUSE			PAGE
1.	Overview ..........................................................................................................................		1
	1.1	Scope .......................................................................................................................	1
	1.2	Purpose ....................................................................................................................	1
2.	Definitions ........................................................................................................................		2
	2.1	General terminology ...................................................................................................	2
	2.2	1284.4-specific terminology .........................................................................................	3
3.	Features and compliance ..................................................................................................		5
	3.1	Overview....................................................................................................................	5
	3.2	Features....................................................................................................................	5
	3.3	Compliance criteria.....................................................................................................	5
	3.4	MLC compatibility criteria............................................................................................	6
4. Theory of operation of the 1284.4 protocol ...........................................................................			7
	4.1	Overview....................................................................................................................	7
	4.2	General packet structure.............................................................................................	7
	4.3	Communication procedures .........................................................................................	8
	4.4	Service discovery .....................................................................................................	10
	4.5	Data transfer and flow control ....................................................................................	11
5.	1284.4 Transactions........................................................................................................		17
	5.1	Overview..................................................................................................................	17
	5.2	Transaction summary ...............................................................................................	17
	5.3	Conversation Control Transactions .............................................................................	19
	5.4	Connection Control Transactions ...............................................................................	25
6. Data link service requirements .........................................................................................			39
	6.1	Overview..................................................................................................................	39
	6.2	Required Services ....................................................................................................	39
Annex A		Bibliography (informative)......................................................................................	41
Annex B		Service Names Registry (normative) ......................................................................	42
Annex C		1284.4 Architecture (informative) ...........................................................................	44
Annex D Example 1284.4 API (informative)..........................................................................			45
	D.1	API Overview............................................................................................................	45

v

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999
D.2	API Services ............................................................................................................	45
D.3	API Usage...............................................................................................................	50
D.4	Mapping API services to 1284.4 transactions ..............................................................	50
Annex E	Implementation Issues (informative) .......................................................................	52

vi

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

1. Overview

1.1 Scope

The packet protocol described by this standard allows a device to carry on multiple, concurrent exchanges of data and/or control information with another device across a single point-to-point link. The protocol is not a device control language. The protocol provides basic transport-level flow control and multiplexing services. The multiplexed information exchanges are independent and blocking of one has no effect on any other. The protocol shall operate over IEEE Std. 1284-1994 interfaces and may operate over other interfaces, such as RS-232, Universal Serial Bus (USB), and IEEE 13941995.

1.2 Purpose

IEEE Standard 1284-1994 defines and describes an updated PC parallel interface by adding multiple modes of operation, which provide for higher speed, bi-directional communication between devices. The IEEE Std. 1284-1994 standard does not provide anything beyond a physical protocol. The 1284.4 standard specifies a point-to-point protocol with one or more layers above the physical interface and below the application. These layers take on the functions and characteristics of the transport and session layers of the OSI model.

1

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

2. Definitions

2.1 General terminology

The following terms and acronyms are used in this standard. The definitions are not intended to be absolute, but they do reflect the use of the terms in this standard.

2.1.1Big-endian: A data format where the most significant byte of a multi-byte object is at the lowest address and the least-significant byte is at the highest address.

2.1.2Byte: An 8-bit value. In this standard, bits are read left to right with the MSB (Most Significant Bit) labeled 7 to LSB (Least Significant Bit) labeled 0 as shown in the following figure:

Bit 7 - MSB

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0 – LSB

2.1.3Connection: A persistent communications path between two endpoints.

2.1.4Device Control Language: A language used to monitor and/or control the state of a device.

2.1.5Endpoint: A consumer or producer of data on a communication link.

2.1.6Flow control: The function performed by a receiving entity to limit the amount of data that is sent by a transmitting entity.

2.1.7ISO: Acronym for International Organization for Standardization. A voluntary, non-treaty organization whose members are designated standards bodies of participating nations, and non-voting observer organizations.

2.1.8Logical channel: One connection over a single physical communication link. There may be multiple logical channels over a single physical communication link.

2.1.9OSI model: Acronym for Open Systems Interconnect model. A seven-layer network communications model developed by an ISO subcommittee that governs communications interchange between systems. The model is an internationally accepted framework of standards for intersystem communications.

2.1.10Packet: A group of bytes, including address, data, and control elements.

2.1.11Point-to-point communications: Communications that take place between exactly two devices.

2.1.12Service discovery: The function of providing transport clients with the ability to dynamically query service availability within a peer transport entity.

2

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

2.2 1284.4-specific terminology

2.2.1Application: A software component that uses the 1284.4 transport.

2.2.2Blocked channel: A channel with at least one blocked endpoint.

2.2.3Blocked endpoint: An endpoint that is unable to send data on a connection due to lack of credit. A blocked endpoint becomes unblocked when it is granted credit to send data on that connection.

2.2.4Channel: An independently flow-controlled connection between a socket on the primary device and a socket on the secondary device. It provides a logical conduit for moving data between the two endpoints.

2.2.5Client: Name used to refer to the software component on one device that uses the services provided by a server on another device. The communication between the client and the server is managed by the protocol defined in this standard.

2.2.6Command: The instruction sent from an initiator to a target directing the target to execute a specified process.

2.2.7Conversation: Canonical name given to the interactions between two 1284.4 peers during the period of time bracketed between corresponding Init and Exit transactions.

2.2.8Credit: A value issued by a 1284.4 implementation on behalf of an endpoint indicating the number of packets that may be received by that endpoint.

2.2.9End-of-message packet: The last packet of a message in the data stream.

2.2.10Initiator: The 1284.4 implementation that initiated a transaction by sending a command.

2.2.11Message: A set of ordered data (possibly empty) that includes a message boundary indication. Message data may span multiple packets. A packet shall not hold data from more than one message.

2.2.12Multiple Outstanding Transactions: A state where more than one transaction has been issued and is pending completion.

2.2.13Out-of-band packet: A packet of exceptional data in the data stream. This type of packet may contain special information relating to the data at this position in the data stream, for example, “End of Job.” Information contained in the out-of-band packet is outside of the scope of this standard.

2.2.14Piggyback Credit: Term used to describe the inclusion of credit inside a 1284.4 packet header. By using piggyback credit, 1284.4 can reduce the overhead of Credit transactions when processing a channel on which data is flowing bidirectionally.

2.2.15Primary device: The device that issued the Init transaction that started the current 1284.4 conversation. There is no priority implied by the assignment of primary and secondary

3

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

devices once the conversation has been established. The assignment of primary status is used only to identify the device that contains the primary sockets.

2.2.16Primary Socket Identifier (PSID): A socket number identifying a particular endpoint on the primary device.

2.2.17Reply: The response sent from a target to an initiator indicating that the target has successfully or unsuccessfully executed the process specified by the command originally sent from the initiator to the target.

2.2.18Reserved: Any protocol elements identified as "reserved" are intended for future standardization. Reserved elements shall not be used. Reserved fields or bits shall be set to 0 and shall not be checked. Values not defined in this standard are reserved.

2.2.19Secondary device: The device that was the target of the Init transaction that started the current 1284.4 conversation. There is no priority implied by the assignment of primary and secondary devices once the conversation has been established. The assignment of secondary status is used only to identify the device that contains the secondary sockets.

2.2.20Secondary Socket Identifier (SSID): A socket number identifying a particular endpoint on the secondary device.

2.2.21Server: The software component on one device that provi des services for use by clients on the same or another device. The transfer of data between the client and the server is managed by the protocol defined in this standard.

2.2.22Service Name: The canonical name of a particular service available for use by a 1284.4 client.

2.2.23Socket: Canonical name given to a 1284.4 endpoint to which or from which data is transmitted.

2.2.24Socket ID (identifier): A byte used to uniquely identify the socket. A socket ID can be well known or can be dynamically assigned.

2.2.25Target: The peer 1284.4 implementation to which the initiator’s command is being sent.

2.2.26Transaction: A 1284.4 command exchange, including both the command and the reply.

2.2.27Transaction Channel: The channel used for 1284.4 commands and replies. The primary socket identifier and the secondary socket identifier for the Transaction Channel are both 0x00.

4

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.