SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SCSI-3 PACKETIZED PROTOCOL __________________________ +-------------------------------------+-------------------------------------+ | GARY R. STEPHENS | ABSTRACT | +-------------------------------------+-------------------------------------+ | | | | | | | November 8, 1991 | | +-------------------------------------+-------------------------------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-------------------------------------+-------------------------------------+ | | SCSI WORKING DOCUMENT | | | | | | | | | | | | | | | | | | | | | | | | | +-------------------------------------+-------------------------------------+ i SCSI WORKING DOCUMENT X3T9.2/91-013 R01 ii SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 NOVEMBER 8, 1991 TO : JOHN LOHMEYER, CHAIRMAN, X3T9.2 FROM : GARY R. STEPHENS IBM CORPORATION D67E/060-1 9000 S. RITA RD. TUCSON, AZ 85719 (602) 799-2246 Subject: SCSI-3 Packetized Protocol (SPP) This document is revision 1 of document 91-013 to incorporate into SCSI a protocol suitable for operation on a serial interface. This interface is called SCSI-3 Packetized Protocol (SPP). Extensions, corrections, and deletions have been made to provide the new capabilities for a serial inter- face. It is intended that the X3T9.3 Fibre Channel be the first serial implementa- tion of the SCSI-3 Packetized Protocol. This document assumes that all par- allel bus operations are a mapping of serial operations onto a parallel bus. This should result in minimal function in a converter device between Fiber Channel and parallel busses. An extensive set of deletions, changes, and additions have been made to the glossary in Section 3. Terminology is used consistently in all sections based on the new terms. All terms used beyond section 3 are defined in this glossary or at first use. Sections 4 through 7 contain the logical system description, the I/O process structure, the information packet structure, and I/O process control. Common commands are now described in the SCSI-3 Command Set standard. The physical interfaces which may be used are described in two other stand- ards: SCSI-3 Parallel Interface (SPI) and SCSI-3 Serial Interface (SSI). Gary R. Stephens i SCSI WORKING DOCUMENT X3T9.2/91-013 R01 ii SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 X3T9.2/90-013 Revision 01 DRAFT PROPOSED AMERICAN NATIONAL STANDARD FOR INFORMATION SYSTEMS - SCSI-3 PACKETIZED PROTOCOL SPP NOVEMBER 8, 1991 Secretariat Computer and Business Equipment Manufacturers Association Abstract: This standard defines functional requirements for the SCSI-3 Packetized Protocol (SPP). SPP permits computers to attach to each other and to intelligent devices. SPP simplifies connecting computers and intelligent device classes including rigid disks, flexible disks, magnetic tape devices, printers, optical disks, and scanners. SPP uses information packets to transfer commands, command parameter data, command response data, logical block data, messages, status, and autosense. SPP uses the Fibre Channel as its primary serial transport layer. Its use is defined in SCSI-3 Serial Interface (SSI). SPP uses the SCSI-3 Parallel Interface (SPI) as an alternative parallel transport layer. SPP establishes one logical level of interpretation for information packets independent of the physical transport layer. The parallel interface simu- lates changes made for the serial protocol and this simplifies parallel interface management. SPP streamlines processing, reduces choices, and adds new functions over SCSI-3 Interlocked Protocol (SIP). All information transfers in SPP are independent of the physical bus used. SPP defines a method for managing mul- tiple paths between computers and attached devices. See the SCSI-3 Command Set (SCS) standard for the common and device class specific commands used with SPP. This is a draft standard proposed American National Standard of Accredited Standards Committee X3. As such, this is not a complete standard. The X3T9 Technical Committee may modify this document as a result of comments received during the X3 approval process for standards. COPYRIGHT NOTICE: This draft proposed standard is based on ANSI X3.131-1990, a document copyrighted by the American National Standards Institute (ANSI). Under the usual ANSI policy for revising standards, this draft standard MAY BE REPRODUCED for review and comment only, without further permission, pro- vided this notice is included. All other rights are reserved. POINTS OF CONTACT: i SCSI WORKING DOCUMENT X3T9.2/91-013 R01 JOHN B. LOHMEYER (X3T9.2 CHAIR) I. DAL ALLAN (X3T9.2 VICE-CHAIR) NCR CORPORATION ENDL 3718 N. ROCK ROAD 14426 BLACK WALNUT COURT WICHITA, KS 67226 SARATOGA, CA 95070 (316) 636-8703 (408) 867-6630 ii SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 This is the second draft of the proposed standard. This document is the result of a project proposal to update SCSI for serial interface operation, called SCSI-3. This document has not been approved by the X3T9.2 committee and has not been reviewed by them as of November 8, 1991. The document structure of SCSI-3 standards is as follows: SCS (SCSI-3 COMMAND SETS) | | +------------------------------+------------------------------+ | | | | SIP (SCSI-3 INTERLOCKED PROTOCOL) SPP (SCSI-3 PACKETIZED PROTOCOL) | | | | | | SPI (SCSI-3 PARALLEL INTERFACE) | | APPENDIX B | | | | | +---------+---------+-------------------+-------------+ | | | TRANSPORT LAYER TRANSPORT LAYER TRANSPORT LAYER APPENDIX A APPENDIX C APPENDIX D INDEPENDENT FCS PHASE EMULATION IEEE P1394 SPP MAY USE ANY ONE OF FOUR TRANSPORT LAYERS. SIP AND SPI ARE THE FOLLOW-ON SCSI-2 STANDARDS. The current editorial assignments are: GARY R. STEPHENS (SPP TECHNICAL EDITOR) IBM CORPORATION 60L/040-1 9000 S. RITA RD TUCSON, AZ 85744 (602) 799-2246 iii SCSI WORKING DOCUMENT X3T9.2/91-013 R01 iv SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 TABLE OF CONTENTS _________________ ---------------------------------------------------------------------- PART 1. SPP INTRODUCTORY MATERIAL SECTION 1. SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 SECTION 2. REFERENCED STANDARDS AND ORGANIZATIONS . . . . . . . . . . 2-1 2.1 Corequisite ANSI Standards . . . . . . . . . . . . . . . . . . . . 2-1 2.2 Reference ANSI Standards . . . . . . . . . . . . . . . . . . . . . 2-1 SECTION 3. GLOSSARY AND CONVENTIONS . . . . . . . . . . . . . . . . . 3-1 3.1 Glossary of Essential SPP Terms . . . . . . . . . . . . . . . . . 3-1 3.2 Editorial Conventions . . . . . . . . . . . . . . . . . . . . . 3-16 3.3 Relationship of Essential SPP Terms . . . . . . . . . . . . . . 3-16 ---------------------------------------------------------------------- PART 2. SPP PROTOCOL SECTION 4. SPP LOGICAL OPERATIONS . . . . . . . . . . . . . . . . . . 4-1 4.1 Logical System Description . . . . . . . . . . . . . . . . . . . . 4-1 4.2 Description of Logical Operations . . . . . . . . . . . . . . . . 4-2 4.3 Mandatory Requirements . . . . . . . . . . . . . . . . . . . . . . 4-5 4.4 Logical System Definition . . . . . . . . . . . . . . . . . . . . 4-6 4.5 I/O Processes . . . . . . . . . . . . . . . . . . . . . . . . . 4-11 4.5.1 I/O Process Parameter Requirements (Mandatory) . . . . . . . 4-11 4.5.2 I/O Process Sense Data (Mandatory) . . . . . . . . . . . . . 4-12 4.5.3 SPP Identification . . . . . . . . . . . . . . . . . . . . . 4-12 4.5.3.1 Initiating Controller Identification (Optional) . . . . 4-13 4.5.3.2 SPP Address for a Port (Mandatory) . . . . . . . . . . . 4-13 4.5.3.3 Logical Units (Mandatory) . . . . . . . . . . . . . . . 4-13 4.5.3.4 Target Routines (Optional) . . . . . . . . . . . . . . . 4-13 4.6 Queued I/O Processes (Mandatory) . . . . . . . . . . . . . . . . 4-14 4.6.1 Untagged I/O Processes (Mandatory) . . . . . . . . . . . . . 4-14 4.6.2 Tagged I/O Processes (Optional) . . . . . . . . . . . . . . 4-15 4.6.3 Concurrent I/O Processes Execution . . . . . . . . . . . . . 4-19 4.7 Programmable Operating Definition (Parallel) (Optional) . . . . 4-19 4.8 I/O Process Termination . . . . . . . . . . . . . . . . . . . . 4-20 4.8.1 Normal I/O Process Termination . . . . . . . . . . . . . . . 4-20 4.8.2 Abnormal I/O Process Termination . . . . . . . . . . . . . . 4-21 4.8.2.1 Initiating Controller Caused Termination . . . . . . . . 4-21 4.8.2.2 Target Controller Caused Termination . . . . . . . . . . 4-21 4.9 Logical Unit Reservation Termination (Mandatory) . . . . . . . . 4-21 4.10 Path Group Operations (Optional) . . . . . . . . . . . . . . . 4-21 4.10.1 Single Path Mode . . . . . . . . . . . . . . . . . . . . . 4-22 4.10.2 Multiple Path Mode . . . . . . . . . . . . . . . . . . . . 4-22 4.10.3 Single Path Status . . . . . . . . . . . . . . . . . . . . 4-22 4.10.4 Multiple Path Status . . . . . . . . . . . . . . . . . . . 4-22 4.11 Assignment Termination (Optional) . . . . . . . . . . . . . . . 4-22 TABLE OF CONTENTS v SCSI WORKING DOCUMENT X3T9.2/91-013 R01 4.12 Path Group Termination (Optional) . . . . . . . . . . . . . . . 4-22 SECTION 5. SPP I/O PROCESS STRUCTURE . . . . . . . . . . . . . . . . . 5-1 5.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.1.1 Command Set Implementation Requirements (Mandatory) . . . . . 5-2 5.1.2 Reserved (Mandatory) . . . . . . . . . . . . . . . . . . . . . 5-2 5.1.3 Command Descriptor Block . . . . . . . . . . . . . . . . . . . 5-3 5.1.4 Operation Code (Mandatory) . . . . . . . . . . . . . . . . . . 5-5 5.1.5 Logical Block Address . . . . . . . . . . . . . . . . . . . . 5-5 5.1.6 Transfer Length . . . . . . . . . . . . . . . . . . . . . . . 5-6 5.1.7 Command Parameter Data Length . . . . . . . . . . . . . . . . 5-7 5.1.8 Command Response Data Length . . . . . . . . . . . . . . . . . 5-7 5.1.9 Control Field (Mandatory) . . . . . . . . . . . . . . . . . . 5-8 5.1.9.1 Link Bit (Mandatory) . . . . . . . . . . . . . . . . . . . 5-8 5.1.9.2 Flag Bit (Mandatory) . . . . . . . . . . . . . . . . . . . 5-9 5.2 Status (Mandatory) . . . . . . . . . . . . . . . . . . . . . . . . 5-9 5.2.1 Status Codes (Mandatory) . . . . . . . . . . . . . . . . . . 5-11 5.2.2 Status Code Reporting Priority (Mandatory) . . . . . . . . . 5-13 5.3 Contingent Allegiance Condition (Mandatory) . . . . . . . . . . 5-14 5.4 Extended Contingent Allegiance Condition (Optional) . . . . . . 5-15 5.5 Asynchronous Event Notification (Mandatory) . . . . . . . . . . 5-16 SECTION 6. SPP INFORMATION PACKET STRUCTURE . . . . . . . . . . . . . 6-1 6.1 Information Packet Structure . . . . . . . . . . . . . . . . . . . 6-1 6.1.1 Interface Control Fields (Mandatory) . . . . . . . . . . . . . 6-2 6.1.2 Interface Logical Elements (Mandatory) . . . . . . . . . . . . 6-6 6.1.2.1 Message Interface Logical Element . . . . . . . . . . . . 6-8 6.1.2.2 Command Descriptor Block Interface Logical Element . . . . 6-8 6.1.2.3 Command Parameter Data Interface Logical Element . . . . . 6-8 6.1.2.4 Command Response Data Interface Logical Element . . . . . 6-8 6.1.2.5 Logical Block Data Interface Logical Element . . . . . . . 6-9 6.1.2.6 Status Interface Logical Element . . . . . . . . . . . . . 6-9 6.1.2.7 Autosense Interface Logical Element (Optional) . . . . . . 6-9 SECTION 7. SPP I/O PROCESS CONTROL . . . . . . . . . . . . . . . . . . 7-1 7.1 Messages (Mandatory) . . . . . . . . . . . . . . . . . . . . . . . 7-1 7.1.1 ABORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6 7.1.2 ABORT I/O PROCESS . . . . . . . . . . . . . . . . . . . . . . 7-6 7.1.3 BUS DEVICE RESET . . . . . . . . . . . . . . . . . . . . . . . 7-7 7.1.4 CLEAR QUEUE . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 7.1.5 I/O PROCESS COMPLETE . . . . . . . . . . . . . . . . . . . . . 7-7 7.1.6 EXTENDED MESSAGE REJECT . . . . . . . . . . . . . . . . . . . 7-8 7.1.7 INITIATE RECOVERY . . . . . . . . . . . . . . . . . . . . . . 7-9 7.1.8 INVALID BUS PHASE DETECTED (Parallel) . . . . . . . . . . . . 7-9 7.1.9 INVALID INFORMATION PACKET . . . . . . . . . . . . . . . . . 7-10 7.1.10 LINKED COMMAND COMPLETE . . . . . . . . . . . . . . . . . . 7-11 7.1.11 LINKED COMMAND COMPLETE (WITH FLAG) . . . . . . . . . . . . 7-12 7.1.12 MODIFY DATA POSITION . . . . . . . . . . . . . . . . . . . 7-12 7.1.13 PARITY ERROR (Parallel) . . . . . . . . . . . . . . . . . . 7-12 7.1.14 RELEASE RECOVERY . . . . . . . . . . . . . . . . . . . . . 7-13 7.1.15 RESEND PREVIOUS INFORMATION PACKET . . . . . . . . . . . . 7-13 7.1.16 SYNCHRONOUS DATA TRANSFER REQUEST (Parallel) . . . . . . . 7-14 7.1.17 SYNCHRONOUS PACKET TRANSFER REQUEST . . . . . . . . . . . . 7-16 7.1.18 TERMINATE I/O PROCESS . . . . . . . . . . . . . . . . . . . 7-18 vi SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.1.19 TRANSFER READY . . . . . . . . . . . . . . . . . . . . . . 7-20 7.2 Command Processing Considerations and Exception Conditions . . . 7-21 7.2.1 Unit Attention Condition . . . . . . . . . . . . . . . . . . 7-21 7.2.2 Incorrect Initiating Controller Connection . . . . . . . . . 7-23 7.2.3 I/O Processes for an Invalid LUN or TRN . . . . . . . . . . 7-23 7.2.4 Parameter Rounding . . . . . . . . . . . . . . . . . . . . . 7-24 7.2.5 Unsuccessful I/O Process Termination Condition . . . . . . . 7-24 7.2.6 Reset Condition (Mandatory) . . . . . . . . . . . . . . . . 7-25 7.2.7 Unsuccessful Information Packet Transfer Condition . . . . . 7-26 7.2.8 Unexpected Disconnect Condition . . . . . . . . . . . . . . 7-26 7.2.9 Attention Condition (Parallel) . . . . . . . . . . . . . . . 7-26 TABLE OF CONTENTS vii SCSI WORKING DOCUMENT X3T9.2/91-013 R01 viii SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 FIGURES _______ 3-1. Relationship of SPP Terms (Part 1 of 7) . . . . . . . . . . . 3-17 3-2. Relationship of SPP Terms (Part 2 of 7) . . . . . . . . . . . 3-18 3-3. Relationship of SPP Terms (Part 3 of 7) . . . . . . . . . . . 3-19 3-4. Relationship of SPP Terms (Part 4 of 7) . . . . . . . . . . . 3-20 3-5. Relationship of SPP Terms (Part 5 of 7) . . . . . . . . . . . 3-21 3-6. Relationship of SPP Terms (Part 6 of 7) . . . . . . . . . . . 3-22 3-7. Relationship of SPP Terms (Part 7 of 7) . . . . . . . . . . . 3-23 4-1. SPP High Level Protocol . . . . . . . . . . . . . . . . . . . . 4-2 4-2. Minimum Logical System Attributes . . . . . . . . . . . . . . 4-10 4-3. Simplified SPP System . . . . . . . . . . . . . . . . . . . . 4-11 4-4. Concurrent I/O Process Execution Rules . . . . . . . . . . . 4-20 5-1. Operation Code Types . . . . . . . . . . . . . . . . . . . . . 5-6 FIGURES ix SCSI WORKING DOCUMENT X3T9.2/91-013 R01 x SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 TABLES ______ 5-1. Typical Command Descriptor Block for Six-Byte Commands . . . . 5-3 5-2. Typical Command Descriptor Block for Ten-Byte Commands . . . . 5-4 5-3. Typical Command Descriptor Block for Twelve-Byte Commands . . . 5-4 5-4. Operation Code . . . . . . . . . . . . . . . . . . . . . . . . 5-5 5-5. Control Field . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 5-6. Status Byte . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 5-7. Status Byte Code . . . . . . . . . . . . . . . . . . . . . . 5-11 5-8. Status Byte Code Reporting Priority . . . . . . . . . . . . . 5-13 6-1. Information Packet Structure . . . . . . . . . . . . . . . . . 6-1 6-2. Interface Control Prefix Fields . . . . . . . . . . . . . . . . 6-2 6-3. Interface Control Suffix Fields . . . . . . . . . . . . . . . . 6-6 6-4. Interface Logical Element . . . . . . . . . . . . . . . . . . . 6-7 6-5. ILE Element Type Codes . . . . . . . . . . . . . . . . . . . . 6-7 7-1. Message Element Format Codes . . . . . . . . . . . . . . . . . 7-2 7-2. Message Codes . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 7-3. Extended Message Element Format . . . . . . . . . . . . . . . . 7-4 7-4. Extended Message Codes . . . . . . . . . . . . . . . . . . . . 7-5 7-5. EXTENDED MESSAGE REJECT Message Format . . . . . . . . . . . . 7-8 7-6. INVALID BUS PHASE DETECTED Message Format . . . . . . . . . . 7-10 7-7. INVALID INFORMATION PACKET Message Format . . . . . . . . . . 7-11 7-8. MODIFY DATA POSITION Message Format . . . . . . . . . . . . . 7-12 7-9. PARITY ERROR Message Format . . . . . . . . . . . . . . . . . 7-12 7-10. RESEND PREVIOUS INFORMATION PACKET Message Format . . . . . . 7-14 7-11. SYNCHRONOUS DATA TRANSFER REQUEST Message Format . . . . . . 7-14 7-12. SYNCHRONOUS PACKET TRANSFER REQUEST Message Format . . . . . 7-17 TABLES xi SCSI WORKING DOCUMENT X3T9.2/91-013 R01 xii SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 PART 1. SPP INTRODUCTORY MATERIAL __________________________________ SECTION 1. SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 SECTION 2. REFERENCED STANDARDS AND ORGANIZATIONS . . . . . . . . . . 2-1 2.1 Corequisite ANSI Standards . . . . . . . . . . . . . . . . . . . . 2-1 2.2 Reference ANSI Standards . . . . . . . . . . . . . . . . . . . . . 2-1 SECTION 3. GLOSSARY AND CONVENTIONS . . . . . . . . . . . . . . . . . 3-1 3.1 Glossary of Essential SPP Terms . . . . . . . . . . . . . . . . . 3-1 3.2 Editorial Conventions . . . . . . . . . . . . . . . . . . . . . 3-16 3.3 Relationship of Essential SPP Terms . . . . . . . . . . . . . . 3-16 Part 1. SPP Introductory Material SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 1. SCOPE _________________ This American National Standard defines the protocol for communicating between interconnecting computers and peripheral devices using the SCSI-3 Packetized Protocol (SPP). Although primarily for use with the SCSI-3 Serial Interface (SSI), it has been mapped to the SCSI-3 Parallel Interface (SPI). SPP features transport layer independence and it uses a logical interpreta- tion of and response to information packets. SPP provides a protocol for the movement of commands, data, and responses between devices. The common commands in this standard and the SCSI-3 Device Command Sets (SDCS) standard provide logical commands and responses. SPP transfers information packet transfers on both the SSI and SPI. SPP supports only buffer-to-buffer transfers of information packets. Each information packet is self-identifying which permits correct routing of information packets for each I/O process within initiating controllers and target con- trollers. SPP includes references to the necessary standards and specifies options to allow inter-operability of devices meeting this standard. SPP assures inter- operability only between two SPP devices having compatible physical trans- mission layer characteristics. The primary objective of the standard is to provide computers with device type independence within a class of devices. SPP permits computer users to attach intelligent devices without requiring modifications to hardware or generic software. Generic software is software capable of handling the man- datory functions for a device class. SPP specifies mandatory function for each device class to make generic software easier to generate. SPP provides for adding special features and functions through vendor specific fields and codes. Such additions may require software changes to use those features and functions. SPP identifies reserved fields and code values for future stand- ardization. A second key objective of the standard is to provide a point of incompat- ibility with the SCSI-3 Interlocked Protocol (SIP). Serial interface oper- ations are, by definition, incompatible. On a parallel bus, properly conforming SIP devices reject all SPP protocol extensions. SPP devices on a parallel bus permit such rejections and allow SIP devices to continue inter- operation with each other without requiring use of the extensions. SPP and SIP devices can share the same parallel bus. SPP and SIP devices cannot operate with each other unless the SPP device changes its definition to SIP mode. SPP devices, both initiating controllers and target controllers, attached to parallel busses, have the option of reverting to the SIP oper- ating mode. A change in definition from a SPP operating mode to a SIP oper- ating mode means the SIP standard defines all subsequent operations. Refer to the SIP standard for the proper protocol. Section 1. Scope 1-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 A third key objective of SPP is to move device-dependent intelligence out to the devices. The command sets allow an attached SPP device to obtain initialization information from other attached SPP devices. Responses iden- tify the device class, device characteristics, and the changeable parameters. Further requests can determine the readiness of the device to operate, the types of media supported by the device, and other pertinent system informa- tion. SPP devices provide parameters required for operation, initialization, or system tuning. The device manages all other parameters. For storage devices, the device models use logical rather than physical addressing for all data blocks. For the direct-access device class, each logical unit can provide information about how many blocks it contains. A logical unit may coincide with all, or part of, a peripheral device, or it may span multiple peripheral devices. SPP provides for connecting multiple initiating controllers and multiple target controllers. SPP also provides control mechanisms to use multiple paths between two devices during an I/O process when there are two or more busses in a logical system. IF A CONFLICT ARISES BETWEEN TEXT, TABLES, AND FIGURES, THE ORDER OF PRECED- ENCE TO RESOLVE CONFLICTS IS TEXT, TABLES, AND LASTLY FIGURES. NOT ALL TABLES AND FIGURES ARE FULLY DESCRIBED IN TEXT. TABLES SHOW DATA FORMATS AND VALUES; FIGURES ARE ILLUSTRATIVE OF THE TEXT AND TABLES. NOTES AND IMPLEMEN- TATION NOTES HAVE BEEN KEPT TO A MINIMUM, BUT WHEN THEY OCCUR THEY DO NOT CONSTITUTE ANY REQUIREMENTS FOR IMPLEMENTORS. Section 2 provides a reference list of prerequisite and corequisite stand- ards. Section 3 provides a comprehensive glossary of terms used in SPP. Section 4 provides a description of logical operations and a a logical system description. Section 5 specifies the SPP command and status structure. Section 6 describes the method for encapsulating logical functions in infor- mation packets. Section 7 introduces messages and protocols for their use to support manda- tory and optional functions and the information packet structure. Section 8 describes the commands and responses common to all SPP devices. The commands in SPP and and SDCS classify commands as mandatory, optional, or vendor specific. SPP devices implement mandatory common commands in SPP and mandatory commands defined for the appropriate device class (from SDCS). SPP devices may implement optional commands and command functions as well. Within each command, there are mandatory functions which a SPP device imple- ments; there may be optional functions within some commands. For any command, a SPP device implements all functions identified as mandatory. 1-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SPP devices implement commands and responses that simplify writing self- configuring software. Such software can "discover" necessary device attri- butes without prior knowledge of specific peripheral device characteristics (such as storage capacity). Many commands also implement a very large logical block address space (2**32 blocks). Some commands implement a smaller logical block address space (2**21 blocks). (Delete These? GRS) APPENDICES ARE NOT PART OF THIS STANDARD. APPENDICES PROVIDE EXTRA EXPLANA- TORY MATERIAL ABOUT SPP. IF A CONFLICT ARISES BETWEEN THE MAIN TEXT AND AN APPENDIX, THE MAIN TEXT TAKES PRECEDENCE. Appendix A contains examples of I/O process management by initiating control- lers and target controllers. (New. Extracted from various sections. GRS) Appendix B describes data integrity in command queuing environments. Appendix C describes normal procedures following a power-on condition. An index is found after the last appendix. Section 1. Scope 1-3 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 1-4 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 2. REFERENCED STANDARDS AND ORGANIZATIONS __________________________________________________ 2.1 COREQUISITE ANSI STANDARDS _______________________________ ANSI X3.4-1977, American Standard Code for Information Interchange (ASCII), ANSI X3.xxx-199x, SDCS ANSI X3.xxx-199x, SPI ANSI X3.xxx-199x, SSI 2.2 REFERENCE ANSI STANDARDS _____________________________ ANSI X3.131-1991, SCSI-2 ANSI X3.xxx-199x, CAM Section 2. Referenced Standards and Organizations 2-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 2-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 3. GLOSSARY AND CONVENTIONS ____________________________________ 3.1 GLOSSARY OF ESSENTIAL SPP TERMS ____________________________________ This section contains a glossary of special terms used in this standard. A segment of text for any glossary entry prefixed by "(Parallel Interfaces.)" or "(Serial Interfaces.)" applies only to implementations which use that par- ticular transport layer. A segment of text for any glossary entry prefixed by "(Initiating Controllers.)" or "(Target Controllers.)" applies only to SPP devices when operating in that mode. +---+ | A | +---+ ACCEPT. When related to I/O processes, the process in a target controller which determines that an I/O process may be executed for the sending initi- ating controller, and if permissible, determines that the I/O process log- ically correct based on order and content of each interface logical element. Contrast with receipt and execute. ACTIVE I/O PROCESS. Both an initiating controller and a target controller may have multiple active I/O processes. An active I/O process may be a current I/O process or it may be disconnected. (Initiating Controller.) An I/O process for which a connect has been made. An I/O process becomes active with the initial connection; the same I/O process may be in the queued I/O process queue of the target controller. (Target Controller.) An I/O process which is in execution (not in the queued I/O process queue). ACTIVE I/O PROCESS QUEUE. A queue in logical elements which contains active I/O processes from the perspective of that logical element. The queue may contain zero or more active I/O processes. The organization of the active I/O process queue is controlled by the logical element. AEN. Asynchronous event notification. AIOP. Active I/O process. AIOPQ. Active I/O process queue. ASCII BYTE. A byte whose value is interpreted for graphic presentation according to the ASCII collating sequence. ASSIGNED. An attribute of a target controller function which permits it to accept I/O processes only from certain path groups. ASYNCHRONOUS EVENT NOTIFICATION. A protocol used by target controllers to notify appropriate initiating controllers of a significant event occurring in the target controller which does not occur while the target controller is Section 3. Glossary and Conventions 3-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 executing an active I/O process (e.g., Unit Attention or medium removal). Detection of the event results in either contingent allegiance or extended contingent allegiance. AUTOMATICALLY PRESENTED SENSE DATA. When contingent allegiance or extended contingent allegiance is established, the target controller notifies the ini- tiating controller by sending a status ILE with a status byte code value of CHECK CONDITION or I/O PROCESS TERMINATED; the target controller prepares sense data appropriate for the error. The target controller may include the sense data as a command response data ILE immediately following the status ILE. If the sense data is transferred in this manner, it is called automat- ically presented sense data or autosense. If the sense data is not included following the status ILE, the target controller preserves the sense data until the initiating controller retrieves it or causes it to be deleted without transfer; this is called pending sense data. This term differen- tiates this data from CDBs, messages, command parameter data, command response data, status and logical block data. AUTOSENSE. Automatically presented sense data. +---+ | B | +---+ BIT. See xx bit. BLOCK. A logical block or physical block. BLOCK PERIPHERAL DEVICE. A peripheral device which is in one of the fol- lowing device classes: direct access, write once, CD-ROM, or optical memory. A peripheral device in a device class considered as block peripheral device can be a source or destination in a COPY, COMPARE, or COPY AND VERIFY command. See stream peripheral device and other peripheral device. BURST. A contiguous set of bytes associated with an I/O process which represents all or part of the logical block data, the command parameter data, or the command response data for a command. Bursts are variable length. A burst may be part of an information packet. A burst is not part of every information packet. BYTE. An 8-bit (octet) construct. BYTE STRING. A contiguous set of ASCII bytes. +---+ | C | +---+ CA. Contingent allegiance. CDB. Command descriptor block. 3-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 CIOP. Current I/O process. COMMAND. A command descriptor block, and associated command parameter data, sent from an initiating controller to a target controller to cause a logical unit or target routine to perform some action for the initiating controller. A command for an active I/O process with linked commands executes to com- pletion before beginning execution of any later command for the same active I/O process. That is, commands within a set of linked commands for an I/O process are not reordered for execution by the target controller function. s may be COMMAND DESCRIPTOR BLOCK. An organized collection of bytes used to communi- cate the fixed length portion of commands. This term differentiates this data from messages, command parameter data, command response data, status, autosense, and logical block data. COMMAND PARAMETER DATA. An organized collection of fields (0 or more in length) provided as an addendum to some command descriptor blocks. This term differentiates this data from messages, CDBs, command response data, status, autosense, and logical block data. COMMAND RESPONSE DATA. An organized collection of fields (0 or more in length) provided in response to some commands (e.g., sense data). This term differentiates this data from messages, CDBs, command parameter data, status, autosense, and logical block data. CONNECT. The initiating controller process which selects an initiator, a target and results in establishing a nexus and an I/O process in a target controller. The connection that results is an initial connection. A connect requires successful information packet transfer. The information packet may not be logically error free. CONNECTION. An initial connection or reconnection. A connection occurs between one initiator and one target on the same SPP bus. A connection begins when conditions exist between an initiator and a target for informa- tion transfer; a connection ends with the next disconnect. (Parallel Inter- faces.) At the end of a successful selection. (Serial Interfaces.) When sending or receiving an information packet. The connection for the sender may end before the connection starts for the receiver. CONTINGENT ALLEGIANCE. A condition in a target controller established when the error is detected and which results in either the target controller sending CHECK CONDITION or I/O PROCESS TERMINATED status for an active I/O process to its initiating controller or in asynchronous event notification. The target controller determines the condition to be of a nature where no recovery procedure requiring exclusive use of the logical unit or target routine is required. The target controller prepares sense data when the error is detected. If the sense data is transferred as autosense, the con- tingent allegiance is terminated upon successful transfer of the information packet(s) containing the status ILE and the sense data ILE(s). COPY MANAGER. A target controller which has implemented the COPY, COMPARE, and/or the COPY AND VERIFY commands. The target controller becomes a copy manager only on accepting one of these three commands and the corresponding Section 3. Glossary and Conventions 3-3 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 command parameter data. A copy manager implements an initiating controller logical element function more complete than that required for asynchronous event notification. CPD. Command parameter data. CRD. Command response data. CURRENT I/O PROCESS. An I/O process connected on a SPP bus. The I/O process may be an active I/O process or it may be a queued I/O process with the ILEs from information packets being routed to the queued I/O process queue in a target controller. (Parallel Interfaces.) Only one I/O process may be current on a single SPI bus. (Serial Interfaces.) Only one I/O process may be current per fiber at either the initiator end of a link or the target end of a link. Zero or more information packets may be between the link end points for the same or different I/O processes. +---+ | D | +---+ DEVICE CLASS. A set of target controllers all having the same logical model and specified independently in SDCS. Mandatory and optional functions are specified including the common commands and functions. All device classes conform to the mandatory requirements of the logical system. DEVICE TYPE. A specific target controller function which implements some or all of the functions for a device class. Each device type implements all mandatory commands and functions for its device class. DISBAND. A process which breaks up a set of paths established as a path group. DISCONNECT. (Parallel interfaces.) The action that occurs when a selected SPP device releases control of the bus, allowing it to go to the BUS FREE phase. (Serial interfaces.) The action that occurs at the end of an informa- tion packet transfer or the transmitter stops sending ordered sets during information packet transfer. +---+ | E | +---+ ECA. Extended contingent allegiance. ESTABLISH A PATH GROUP. A process to form a non-empty set of paths as a group which are treated as equivalent for most I/O process activity. EXECUTE. When applied to an active I/O process, only interface logical ele- ments which have been received and accepted are acted upon by the logical element. Interface logical elements which are received and not accepted 3-4 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 result in an appropriate message or a contingent allegiance to report the error. Contrast with receive and accept. EXPLICITLY NAMED PATH. An explicitly named path exists when the initiating controller successfully completes an active I/O process to transfer the ICID of the initiating controller to a LUN or TRN and the target controller trans- fers its selected port number to the initiating controller. EXTENDED CONTINGENT ALLEGIANCE. A condition in a target controller estab- lished when an error is detected and which results in either the target con- troller sending CHECK CONDITION or I/O PROCESS TERMINATED status for an active I/O process to an initiating controller or in asynchronous event notification. The target controller determines that the condition is a type where a recovery procedure requires exclusive use of the logical unit or target routine. The target controller prepares sense data when the error is detected. For AEN, the sense data is transferred in the SEND command. For an active I/O process, the sense data may be transferred as autosense. The target controller may preserve the sense data in the target controller for retrieval by a REQUEST SENSE command or deleted by the initiating controller without transfer. A special protocol notifies the initiating controller that the condition exists to differentiate it from contingent allegiance. A pro- tocol notifies the target controller when the initiating controller has com- pleted its implementation of the recovery procedure. The target controller recovery procedure is vendor specific. The initiating controller is not required to follow the recommended recovery procedure. Failure to follow the recommended procedure may have an undesirable effect on the target con- troller, the target controller function, or attached peripheral devices. +---+ | F | +---+ FIELD. A set of one or more contiguous bits. +---+ | G | +---+ GROUPED. The state of an explicitly named path when it is a member of an established path group. +---+ | H | +---+ H_C NEXUS. A nexus which exists between an initiating controller and a target controller. An H_C nexus, or any of its derivatives, may use more than one initiator and one target combination for connections during an active I/O process when using the multiple path option of SPP. Section 3. Glossary and Conventions 3-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 H_C_L NEXUS. A nexus which exists between an initiating controller, a target controller, and a logical unit. This relationship replaces the prior H_C_x nexus. H_C_L_Q NEXUS. A nexus between an initiating controller, a target con- troller, a logical unit, and a queue tag. This relationship replaces the prior H_C_x_y nexus. H_C_R NEXUS. A nexus which exists between an initiating controller, a target controller, and a target routine. This relationship replaces the prior H_C_x nexus. H_C_X NEXUS. A nexus which is either an H_C_L or H_C_R nexus. This relationship replaces the prior H_C_x_y nexus. H_C_X_Y NEXUS. A nexus which is either an H_C_x or H_C_L_Q nexus. This relationship replaces the prior H_C nexus. H_I_T_C NEXUS. An H_C nexus, or one of its derivatives, between an initi- ating controller and a target controller, which operates in single path mode. +---+ | I | +---+ I/O PROCESS. An I/O process consists of a set of connections consisting of one initial connection and zero or more reconnections. The set of con- nections relate to the exchange of information packets. The set of con- nections pertains to a nexus where zero or more commands may be transferred. An I/O process begins with the establishment of a nexus. An I/O process may be either untagged or tagged with a queue tag. When an I/O process contains one or more commands, the active I/O process normally ends with the discon- nect following successful transfer of a COMMAND COMPLETE message, if ECA does not exist. When an I/O process consists of only message exchanges, the active I/O process ends with the disconnect at the receiver of the the last message of the exchange. If CA exists, the I/O process ends with the transfer or deletion of the sense data for the contingent allegiance. If ECA exists, the I/O process ends with the disconnect following successful transfer of the RELEASE RECOVERY message from the same initiating controller. An I/O process ends abnormally with the disconnect following execution of an ABORT, an ABORT TAG, a BUS DEVICE RESET, or a CLEAR QUEUE message. An I/O process also ends abnormally when unexpected disconnect occurs. (Parallel Interfaces.) An I/O process ends abnormally with the disconnect following detection of the RESET event. I/O PROCESS QUEUE. An active I/O process queue or a queued I/O process queue. The contents of the I/O process queues in an initiating controller and a target controller may be different. ICID. Initiating controller ID. IDENTIFY FUNCTION. A process in logical elements used to identify the logical unit or target routine, and optionally a queue tag to establish or 3-6 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 reconnect to a correct nexus. The identify function determines whether an information packet establishs a new nexus or whether it is processed as part of an established nexus (i.e., an existing active I/O process or a queued I/O process). ILE. Interface logical element. IMPLICITLY NAMED PATH. An implicitly named path exists when the initiating controller has not transferred its ICID to the target controller, but the initiating controller has made at least one connect to the LUN or TRN. The target controller has transferred its selected port number to the initiating controller. INFORMATION PACKET. A set of bytes containing interface control fields and at least one interface logical element. INITIAL CONNECTION. An initial connection is the result of a connect. INITIATING CONTROLLER. A logical element which principally starts I/O proc- esses. Active I/O processes execute using the services of one or more ports in the initiating controller. (Serial Interfaces.) The ports may be for one or more Fiber Channel nodes. INITIATING CONTROLLER ID. An initiating controller ID is an identifier to uniquely name an initiating controller which is communicated to target con- trollers over the interface as part of the multiple path option. INITIATOR. An SPP port operating in initiator mode through which an initi- ating controller starts and executes I/O processes. An initiator usually attaches to an initiating controller. An initiator uses one port to one SPP bus. INITIATOR MODE. The current operating mode of a port which permits it to initiate I/O processes at another port. (Parallel interfaces.) An initiator selects another port, which is in target mode, on the same SPI bus. (Serial interfaces.) An initiator establishes an H_C nexus with another port using a link and possibly fabric. INTERFACE CONTROL FIELDS. An organized collection of bytes used to encapsulate interface logical elements into information packets. The trans- port layer interprets some of these fields to accomplish proper routing of information packets between initiating controllers and target controllers. INTERFACE LOGICAL ELEMENTS. Organized collections of bytes containing self- describing messages, CDBs, command parameter data, command response data, status, or logical block data. INVALID. An illegal, reserved, or unsupported bit, field, code value, bus phase, or protocol sequence. Section 3. Glossary and Conventions 3-7 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---+ | J | +---+ . +---+ | K | +---+ . +---+ | L | +---+ LBD. Logical block data. LOGICAL BLOCK. A unit of data supplied from or requested by an initiating controller usually for a peripheral device. A logical block may be fixed or variable in length. LOGICAL BLOCK DATA. A burst of bytes from or to a logical unit for a logical block. This term differentiates these data from messages, CDBs, command parameter data, command response data, status, and autosense. LOGICAL ELEMENT. An initiating controller or a target controller. LOGICAL PATH. A logical path is the set of all paths which have the same ICID and LUN or TRN in the same target controller. The set of paths identify the routes active I/O processes may take between an initiating controller and a logical unit or target routine. LOGICAL SYSTEM. (Target Controllers.) A logical system is the set of initi- ating controllers having at least one port attached to at least one port of the target controller and from which a connect has been made. (Initiating Controllers.) A logical system is the set of all logical units and target routines to which a connect has been made. The set of paths available to an I/O process is fixed when each H_C_x_y nexus is established; an H_C nexus uses only the path where the connect was made. LOGICAL UNIT. An addressable function within a target controller which exe- cutes active I/O processes. A logical unit has a name, the logical unit number or LUN, and a set of commands to execute. Often, there is a one-to-one mapping between peripheral devices and logical units, but this is not required. A logical unit may be part of, all of, composed of more than one peripheral device, or it may have no peripheral device. LOGICAL UNIT NUMBER. The name of a logical unit used during an I/O process to select it to execute an I/O process for an H_C_L or H_C_L_Q nexus. LSB. Least significant bit. 3-8 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 LU. Logical unit LUN. Logical unit number. +---+ | M | +---+ M**N. A mathematical expression representing the number m raised to the n-th power. Both m and n are integer decimal numbers. MESSAGE. An organized collection of bytes (1 or more) used for control between an initiating controller and a target controller for control of a nexus. Some message establish conditions which persist beyond the I/O process in which the condition was established. This term differentiates these data from a CDB, command parameter data, command response data, status, autosense, and a logical block. MSB. Most significant bit. MSG. Message. MULTIPLE PATH MODE. A condition for one I/O process where connections may be made on any path in the established path group where the connect occurred. While operating in multiple path mode, an I/O process may operate in single path status mode or multiple path status mode; the initiating controller establishes the desired operating condition when the connect is made. See definitions for single path status mode and multiple path status mode. For an implicitly named path or an ungrouped path see single path mode. MULTIPLE PATH STATUS MODE. A condition in a path group where any status is transferred on any path in the established path group where a connect is made. +---+ | N | +---+ NAME BIT. A field containing only one bit. "name" is replaced with a uniquely identifying phrase. NEXUS. A relationship between an initiating controller and a target con- troller that begins with an initial connection and ends with the completion of the associated I/O process. The relationship may be restricted to operate in single path mode. The relationship may be restricted to a single logical unit or target routine through the identify function. Each initiating con- troller and target controller may have zero, one, or more nexus established at one time. Section 3. Glossary and Conventions 3-9 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---+ | O | +---+ ONE. A true signal value, a single bit field with a value of 1b, or a field value numerically equal to 1b. OTHER PERIPHERAL DEVICE. A peripheral device which is in one of the fol- lowing device classes: scanner, medium changer, or graphic arts (2 classes). A peripheral device in a device class considered as 'other' cannot be a source or destination in a COPY, COMPARE, or COPY AND VERIFY command. See stream and block peripheral device definitions. +---+ | P | +---+ PAGE. Regular, self-describing sets of fields used with some command param- eter data and command response data. Each page has a page code. PAGE CODE. A field within a page whose value is unique within a command. The page code provides the means to interpret the remaining fields in a page. PARAMETER. A parameter is the value of a field. PASSWORD. An identifier used to permit otherwise unauthorized access to an assigned target controller function. PATH. A path is a named link between an initiating controller and a target controller function. At least one connect has been made from the initiating controller to the target controller function. The name consists of: an ICID; an SPP Address for the an initiator port; the initiating controller port number; the target controller port number; an SPP Address for the target controller; and, the valid LUN or TRN of the selected logical unit or target routine. A path begins as an implicitly named path and may be modified to an explicitly named path by an initiating controller. Only paths which have been explicitly named participate in established path groups. A path may be grouped or ungrouped. PATH GROUP. A path group is a cooperating set of paths in a logical path. The logical path consists a non-empty set of explicitly named paths. PENDING SENSE DATA. sense data for a contingent allegiance or extenced con- tingent allegiance not sent to the initiating controller as an autosense ILE when the status for the I/O process was sent. It is held in the target con- troller until retrieved or deleted by an action from the initiating con- troller, or by an internal target controller equivalent to a power cycle. PERIPHERAL DEVICE. A physical device attaching to an SPP device. A periph- eral device and a SPP device may be one unit. Examples of peripheral devices are: magnetic disks, an array of magnetic disks, printers, optical disks, magnetic tapes, and initiating controllers. Initiating controllers, as processor device class, are also peripheral devices. 3-10 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 PHYSICAL BLOCK. The minimum recording unit, in bytes, for certain device classes. The physical block may be fixed or variable in length and is device class dependent. PORT. A port is the name for the portion of an SPP device where it attaches to one SPP bus. An SPP device may have more than one port. Each port may attach to a different SPP bus. One port functions in either initiator mode or target mode during a connection. Each port has an SPP address. (Parallel interfaces.) Initiating controllers translate the SPP address into a SPI ID for arbitration. PORT NUMBER. A unique number for each port assigned by the controlling logical element. +---+ | Q | +---+ QIOP. Queued I/O process. QIOPQ. Queued I/O process queue. QUEUE TAG. The parameter associated with an I/O process that uniquely iden- tifies it from other tagged I/O processes for a logical unit from the same initiating controller. The queue tag is not related to the path or paths used for the I/O process; it is related only to the initiating controller and logical unit. QUEUED I/O PROCESS. An I/O process that is in the queued I/O process queue and is not in the active I/O process queue. The state of an I/O process in an initiating controller may be different from the state in the target con- troller associated with the same I/O process. (Initiating Controller.) An I/O process for which a connect has not been made. (Target Controller.) An untagged or a tagged I/O process which is not active. QUEUED I/O PROCESS QUEUE. A queue in either an initiating controller or a target controller to hold all or part of zero or more I/O processes before acceptance and execution. The I/O processes may be either tagged or untagged. QUEUEING FUNCTION. A process in a logical element which transfers or relates ILEs from an information packet to an I/O process in the queued I/O process queue (i.e., not active). The organization of the queued I/O process queue is controlled by the logical element. +---+ | R | +---+ RECEIVE. When applied to I/O processes, the result of transfer of an infor- mation packet between two logical elements. An information packet is checked and must be accepted before any action is taken relative to its ILEs. An Section 3. Glossary and Conventions 3-11 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 information packet which is received from an initiating controller not per- mitted access to a target controller is rejected with an appropriate status. An information packet which is received from an authorized initiaging con- troller, but which has logical construction or content errors is not accepted; the I/O process is termintated with a message or contingent alle- giance as appropriate for the error. Contrast with accept and execute. RECONNECT. The act of reviving a nexus to continue an I/O process. The con- nection may be on the same initiator and target pair as the last connection or on a different pair when using multiple path mode. The action taken to revive the nexus depends on the initiating controller conditions established in the target controller. A reconnect results by successfully establishing the conditions appropriate for the physical bus to transfer an information packet associated with a nexus between an initiator and a target. RECONNECTION. A reconnection is the result of a reconnect. (Parallel Inter- faces.) After a connect, a reconnection exists from the end of a subsequent SELECTION phase by either the initiating controller or the target controller until the next disconnect for an I/O process in an initiating controller. (Serial Interfaces.) After a connect, a reconnection exists while the receiving port is actively receiving an information packet for an I/O process in an initiating controller (i.e., transmission does not constitute a recon- nection since the fabric may prevent delivery). RESERVED. The term used for bits, fields, code values, and bus phases set aside for future standardization. +---+ | S | +---+ SCSI. SCSI-3. SCSI-3. Small Computer System Interface - 3 (X3.xxx-199X). SENSE DATA. Autosense data or command response data formatted according to SPP rules which identify the reason for contingent allegiance or extended contingent allegiance. The target controller also prepares sense data according to the same rules when a REQUEST SENSE command executes and neither a contingent allegiance nor an extended contingent allegiance condition exists. For contingent allegiance and extended contingent allegiance, Sense data may be held in the target controller and transferred when requested by a REQUEST SENSE command or as an autosense ILE following the status ILE when the error is reported. SIGNAL ASSERTION. (Parallel interfaces.) The act of driving a signal to the true state. (??? SSI GRS) SIGNAL NEGATION. (Parallel interfaces.) The act of driving a signal to the false state or allowing the cable terminators to bias the signal to the false state. (??? SSI GRS) 3-12 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SIGNAL RELEASE. (Parallel interfaces.) The act of allowing the cable termi- nators to bias the signal to the false state. (??? SSI GRS) SINGLE PATH MODE. A condition in a path group for one I/O process where single path status mode is in effect and all connections are made on the path where the connect occurred. An implicitly named path or an ungrouped path is in single path mode since it cannot cooperate with any other path. SINGLE PATH STATUS MODE. An attribute of a path group where status leading to a contingent allegiance or extended contingent allegiance is transferred on the path where the connect occurred. An implicitly named path or an ungrouped path is in single path status mode since it cannot cooperate with any other path. SINGULAR. An attribute of an SPP command which prohibits its execution if it follows a command in an I/O process which has the Link bit set to 1 or which has the Link bit in its CDB is set to 1. SPI ID. (Parallel interfaces.) The bit-significant representation of the SPP address referring to one of the data bus signal lines available to the SPP device, excluding parity lines. SPP. SCSI-3 Packetized Protocol. SPP ADDRESS. The unique address for one port on an SPP device. The SPP address is unique on a SPP bus. Multiple ports on the same SPP device con- nected to the same SPP bus have different SPP addresses. The form of the SPP address varies with the physical interface used. The field value assigned to the source and destination fields of the interface control prefix fields. (Parallel interfaces.) The SPP address is a translation of the SPI ID for its port. The number of valid SPP addresses on a SPI bus is a function of the maximum data bus width of all attached ports. (Serial interfaces.) Neither the SPP address nor the number of SPP devices on a serial interface translates to the number of signal lines in the interface. SPP BUS. (Parallel interfaces.) A SPI port and the set of all ports, inter- connecting cables, etc., to and through which the port communicates. If a SPI port has bus signals connecting two external connectors, that portion of the SPI port is part of the SPP bus. The maximum number of SPI ports is 8 times bus width (in bytes, not including parity signals). (Serial inter- faces.) The set of all SPP devices to which a single SPP port can communi- cate. SPP DEVICE. A device capable of attaching to one or more SPP busses via one or more ports. The device may allow a port to function in either initiator mode or target mode for any one connection. Each SPP port is capable of both modes. SPP PORT. Port. STATUS. One field sent from a target controller at the completion of each command. Status is also produced to report some conditions which occur in an I/O process when a command is not executing. Most status reports result in ending an I/O process. This term differentiates these data from a message, a Section 3. Glossary and Conventions 3-13 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 CDB, command parameter data, command response data, autosense, and logical block data. STORAGE DEVICE. A peripheral device which is capapable of reading and optionally writing logical blocks to a medium. Some storage devices have the medium prepared so that a write process is not incorporated in the storage device (e.g., CDROM). Most storage devices permit writing at least once; reading may occur multiple times in all storage devices. STREAM PERIPHERAL DEVICE. A peripheral device which is in one of the fol- lowing device classes: sequential access, printer, processor or communi- cations. A peripheral device in a device class considered as 'stream' can be a source or destination in a COPY, COMPARE, or COPY AND VERIFY command. See block and other peripheral device definitions. SUPERVISOR COMMAND. A command which may not be executed by a target con- troller unless specifically authorized. +---+ | T | +---+ TARGET. An SPP port, operating in target mode, thorough which I/O processes pass for execution by a target controller function. A target usually attaches to a target controller. A target uses one port to one SPP bus. TARGET CONTROLLER. A logical element which principally executes I/O proc- esses. Active I/O processes execute using the services of one or more ports available to the target controller in target mode. (Serial Interfaces.) The ports may reside in one or more Fiber Channel nodes. TARGET CONTROLLER FUNCTION. A logical unit or a target routine. TARGET MODE. The current operating mode of a port which permits the port to be selected by another port on the same SPP bus. TARGET ROUTINE. An addressable function within a target controller which executes active I/O processes. A target routine has a name, a target routine number or TRN, and a command set to execute. TARGET ROUTINE NUMBER. The name of a target routine used during an I/O process to select it to execute an I/O process. THIRD-PARTY. For copy operations, third-party means a copy operation managed by one target controller which is not a source or destination of the copy operation. For multiple path operations, third-party means an assignment made for a path group from another path group. TR. Target routine. TRN. Target routine number. 3-14 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---+ | U | +---+ UNASSIGNED. An attribute of target controller functions which permits the function to respond to I/O processes on any path. UNEXPECTED DISCONNECT. A disconnection that occurs because of a protocol error. UNGROUPED. The state of a path when it is not a member of a path group. The path may be an implicitly named path or an explicitly named path. +---+ | V | +---+ VENDOR SPECIFIC. Something (e.g., a bit, field, code value, etc.) this standard identifies, but its use is not defined by this standard and may be used differently in various implementations. VS. Vendor specific. +---+ | W | +---+ . +---+ | X | +---+ XX. Digits 0-9, except those used as section numbers, in the text of this standard that are not immediately followed by lower-case "b" or "h" are decimal values. Large numbers are not separated by commas or spaces (e.g., 12345; not 12,345 or 12 345). XXB. Digits 0 and 1 immediately followed by lower-case "b" are binary values. XXH. Digits 0-9 and the upper-case letters "A"-"F" immediately followed by lower-case "h" are hexadecimal values. Section 3. Glossary and Conventions 3-15 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---+ | Y | +---+ . +---+ | Z | +---+ ZERO. A false signal value or a field with a value of 0b in each bit posi- tion. 3.2 EDITORIAL CONVENTIONS __________________________ Certain words and terms used in this standard have specific meanings beyond the normal English meaning. Glossaries define these words and terms or the definition appears at first use in the text. Names of signals, phases, mes- sages, commands, statuses, sense keys, additional sense codes, and additional sense code qualifiers are in all upper-case (e.g., REQUEST SENSE). Normal English capitalization (or lack thereof) is used for other words. Words have the normal technical English definition unless the word or phrase is defined in context or in a glossary, then that definition is used. Some words may have definitions unique to the sections where they are used. Every effort has been made to limit the number of such instances. 3.3 RELATIONSHIP OF ESSENTIAL SPP TERMS ________________________________________ Some terms defined in the glossaries of this section, have a relationship to one another as shown pictorially below. 3-16 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | LOGICAL SYSTEM | | | | | | - SSI BUS OR SPI BUS | | | | - INITIATING CONTROLLER -> PORT -> PORT -> TARGET CONTROLLERS -> LU OR|TR | | | | (CONNECT) | | - LOGICAL SYSTEM CONSISTS OF ALL LU OR TR | | FOR WHICH A CONNECT HAS BEEN MADE | | - HAS AN ICID | | | | - LU OR TR -> TARGET CONTROLLER -> PORT -> PORT -> INITIATING CONTROLL|R | | | | (CONNECT) | | - LOGICAL SYSTEM CONSISTS OF ALL INITIATING CONTROLLERS | | FROM WHICH A CONNECT HAS BEEN MADE | | - HAS A LUN OR TRN, RESPECTIVELY | | - ASSIGNED OR UNASSIGNED | | | | - LOGICAL PATH | | - ICID || LUN OR TRN IN SAME TARGET CONTROLLER | | - PATH (PHYSICAL) | | - ICID || INITIATOR PORT NUMBER || INITIATOR SPP ADDRESS | | || TARGET SPP ADDRESS || TARGET PORT NUMBER | | || LUN OR TRN | | - IMPLICITLY NAMED PATH | | - UNGROUPED | | - SINGLE PATH MODE | | - SINGLE PATH STATUS MODE | | - EXPLICITLY NAMED PATH | | - UNGROUPED | | - GROUPED | | | | - PATH GROUP | | - ONLY EXPLICITLY NAMED PATHS | | - UNGROUPED PATHS | | - SINGLE PATH MODE | | - SINGLE PATH STATUS MODE | | - GROUPED PATHS | | - MULTIPLE PATH MODE DEFAULT | | - SINGLE PATH MODE SELECTABLE | | - SINGLE PATH STATUS MODE OR MULTIPLE PATH STATUS MODE | | - MAY HAVE A PASSWORD | | | +---------------------------------------------------------------------------+ Figure 3-1. Relationship of SPP Terms (Part 1 of 7) Section 3. Glossary and Conventions 3-17 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | LOGICAL ELEMENT | | | | | | - AN INITIATING CONTROLLER (HAS AN ICID) | | - STARTS I/O PROCESSES | | | | - A TARGET CONTROLLER | | - EXECUTES I/O PROCESSSS | | - HAS ONE OR MORE LOGICAL UNITS | | - HAS A LUN | | - FIRST LUN IS ZERO, CONTIGUOUS NUMBERING | | - HAS A COMMAND SET | | - HAS A PERIPHERAL DEVICE CLASS | | - HAS ZERO OR MORE PERIPHERAL DEVICES | | - MAY HAVE LOGICAL BLOCKS | | - MAY BE RESERVED | | - MAY HAVE AN EXTENT RESERVED | | - HAS ZERO OR MORE TARGET ROUTINES | | - HAS A TRN | | - FIRST TRN IS ZERO, CONTIGUOUS NUMBERING | | - HAS A COMMAND SET | | - HAS A PERIPHERAL DEVICE CLASS | | | | - ATTACHES TO AT LEAST ONE SPP BUS | | | | - HAS AT LEAST ONE PORT | | - RETAINS TRANSFER PARAMETERS BY PORT || OTHER LOGICAL ELEMENT | | - IN INITIATOR MODE BECOMES AN INITIATOR | | - IN TARGET MODE BECOMES A TARGET | | - HAS A SPP ADDRESS (BECOMES SPI ID - PARALLEL) | | | | - MAINTAINS NEXUS STATUS AND CONTROL | | | | - MAINTAINS I/O PROCESS STATUS AND CONTROL | | | | - HAS A QUEUED I/O PROCESS QUEUE | | - HAS ZERO OR MORE QUEUED I/O PROCESSES | | | | - HAS AN ACTIVE I/O PROCESS QUEUE | | - HAS ZERO OR MORE ACTIVE I/O PROCESSES | | | | - HAS A MAXIMUM OF ONE CURRENT I/O PROCESS PER PORT | | - SELECTED FROM ACTIVE I/O PROCESS QUEUE OR | | QUEUED I/O PROCESS QUEUE | | - RETURNED TO SAME QUEUE AT END OF CONNECTION | | | +---------------------------------------------------------------------------+ Figure 3-2. Relationship of SPP Terms (Part 2 of 7) 3-18 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | NEXUS | | | | - H_C NEXUS | | - H_C_X_Y NEXUS | | - H_C_X NEXUS | | - H_C_L | | - H_C_R | | - H_C_L_Q | | | | - FOR SINGLE PATH MODE REPLACE H_C WITH H_I_T_C | | | | - REQUIRES AN I/O PROCESS | | - HAS ZERO OR MORE COMMANDS | | - MADE UP OF ONE OR MORE INFORMATION PACKETS | | - MAY BE A QUEUED I/O PROCESS IN QUEUED I/O PROCESS QUEUE | | - MAY HAVE A QUEUE TAG | | - MAY BECOME A CURRENT I/O PROCESS WITH ANY | | CONNECTION ON THE ELIGIBLE SET OF PATHS | | STARTED BY AN INITIATING CONTROLLER | | - MAY BE AN ACTIVE I/O PROCESS IN ACTIVE I/O PROCESS QUEUE | | - QUEUED I/O PROCESSES TRANSFER TO ACTIVE I/O PROCESS QUEUE | | FOR EXECUTION | | - MAY HAVE A QUEUE TAG | | - MAY BECOME A CURRENT I/O PROCESS WITH ANY | | CONNECTION ON THE ELIGIBLE SET OF PATHS | | | | LEGEND: | | | | H = INITIATING CONTROLLER | | C = TARGET CONTROLLER | | I = INITIATOR | | T = TARGET | | | | | +---------------------------------------------------------------------------+ Figure 3-3. Relationship of SPP Terms (Part 3 of 7) Section 3. Glossary and Conventions 3-19 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | INFORMATION PACKET | | - INTERFACE CONTROL FIELDS | | - INTERFACE CONTROL PREFIX FIELDS | | - INTERFACE CONTROL SUFFIX FIELDS | | - INTERFACE LOGICAL ELEMENTS | | | | | | INTERFACE LOGICAL ELEMENTS | | | | - MESSAGE | | - COMMAND DESCRIPTOR BLOCK | | - COMMAND PARAMETER DATA | | - BURST | | - MAY HAVE PAGES | | - PAGE CODES | | - MAY USE MULTIPLE PATHS | | - COMMAND RESPONSE DATA | | - BURST | | - MAY HAVE PAGES | | - PAGE CODES | | - MAY CONTAIN SENSE DATA | | - MAY USE MULTIPLE PATHS | | - LOGICAL BLOCK DATA | | - BURST | | - MAY USE MULTIPLE PATHS | | - STATUS | | - SOME CODES CAUSE CONTINGENT ALLEGIANCE | | - HAS PRESERVED SENSE DATA | | - MAY BE TRANSFERRED AS AUTOSENSE | | - ASYNCHRONOUS EVENT NOTIFICATION ALLOWED | | - SOME CODES MAY CAUSE EXTENDED CONTINGENT ALLEGIANCE | | - HAS PRESERVED SENSE DATA | | - MAY BE TRANSFERRED AS AUTOSENSE | | - ASYNCHRONOUS EVENT NOTIFICATION ALLOWED | | - OTHER CODES - NO ALLEGIANCE | | - AUTOSENSE | | - CONTAINS ONLY SENSE DATA | | - BURST | | | +---------------------------------------------------------------------------+ Figure 3-4. Relationship of SPP Terms (Part 4 of 7) 3-20 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | LOGICAL ACTIVITY TERMS (OVER TIME) | | | | --------- INITIATING CONTROLLER QUEUED I/O PROCESS -------- | | ------------------------ BECOMES -------------------------- | | --------- INITIATING CONTROLLER ACTIVE I/O PROCESS -------- | | ------------------------ USES -------------------------- | | ------------------------- NEXUS --------------------------- | | ------ BECOMES ------ ------ BECOMES ----- | | CURRENT I/O PROCESS CURRENT I/O PROCESS | | | | I/O BUS ACTIVE | | +-------------------+ +------------------+ | | | | | | | | ---+ +------------------+ +--- | | I/O BUS INACTIVE | | INFORMATION PACKET INFORMATION PACKET | | TRANSFER OUT TRANSFER OUT | | | | CONNECTION DISCONNECT CONNECTION DISCONN|CT | CONNECT RECONNECT | | INITIAL CONNECTION RECONNECTION | | | | --------------------- ESTABLISHES ----------------------- | | ---------------------- NEXUS ------------------------ | | ------------------------ BECOMES -------------------------- | | ----------- TARGET CONTROLLER QUEUED I/O PROCESS ---------- | | ------------------------ BECOMES -------------------------- | | ----------- TARGET CONTROLLER ACTIVE I/O PROCESS ---------- | | ------ BECOMES ------ ------ BECOMES ----- | | CURRENT I/O PROCESS CURRENT I/O PROCESS | | | | I/O BUS ACTIVE | | +-------------------+ +------------------+ | | | | | | | | ---+ +------------------+ +--- | | I/O BUS INACTIVE | | INFORMATION PACKET INFORMATION PACKET | | TRANSFER IN OR OUT TRANSFER IN OR OUT | | | | CONNECTION DISCONNECT CONNECTION DISCONN|CT | RECONNECT RECONNECT | | RECONNECTION RECONNECTION | | | | ------------------ I/O PROCESS TERMINATES ----------------- | | | | | | CONNECTION | | - FROM A CONNECT RESULTS AN INITIAL CONNECTION | | - FROM A RECONNECT RESULTS IN A RECONNECTION | | - EACH ENDS WITH A DISCONNECT | | | +---------------------------------------------------------------------------+ Section 3. Glossary and Conventions 3-21 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 Figure 3-5. Relationship of SPP Terms (Part 5 of 7) +---------------------------------------------------------------------------+ | | | SPP DEVICE | | | | CONFIGURATIONS TO SEND AN INFORMATION PACKET | | FOR A CONNECT OF AN I/O PROCESS | | | | SPP DEVICE IN INITIATOR MODE | | | | | | +--------------------------+ | | | SPP DEVICE | | | +-----------+--------------------------| | | |INITIATING|| ||SPP PORT | | | |CONTROLLER|| INITIATOR || SPP ADDRESS |---SSI OR SPI BUS- | | | || MODE || SPI ID | | | | ICID || || (PARALLEL) | | | +--------------------------------------+ | | | | | | +--------------------------+ | | | SPP DEVICE | | | +----------------------+--------------------------| | | |PERIPHERAL|| TARGET || ||SPP PORT | | | |DEVICE(S) ||CONTROL- || INITIATOR || SPP ADDRESS |-SSI OR SPI BUS- | | | || LER || MODE || SPI ID | | | | || || || (PARALLEL) | | | +-------------------------------------------------+ | | | | | | | +---------------------------------------------------------------------------+ Figure 3-6. Relationship of SPP Terms (Part 6 of 7) 3-22 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | SPP DEVICE | | | | CONFIGURATIONS TO RECEIVE AN INFORMATION PACKET | | FOR A CONNECT OF AN I/O PROCESS | | | | SPP DEVICE IN TARGET MODE | | | | | | +-----------------------+ | | | SPP DEVICE | | | +------------------------------+-----------------------| | | |PERIPHERAL||LOGICAL|| TARGET || ||SPP PORT | | | | DEVICE ||UNIT/ ||CONTROL-|| TARGET || SPP ADDRESS |---SSI OR SPI |US- | |----------||TARGET || LER || MODE || | | | |PERIPHERAL||ROUTINE|| || || SPI ID | | | | DEVICE || || || || (PARALLEL) | | | +------------------------------------------------------+ | | | | | | +-----------------------+ | | | SPP DEVICE | | | +--------------------------------------------| | | |LOGICAL|| || ||SPP PORT | | | |UNIT/ ||INITIATING|| TARGET || SPP ADDRESS |---SSI OR SPI BUS- | | |TARGET ||CONTROLLER|| MODE || SPI ID | | | |ROUTINE|| || || (PARALLEL) | | | +--------------------------------------------+ | | | | | +---------------------------------------------------------------------------+ Figure 3-7. Relationship of SPP Terms (Part 7 of 7) Section 3. Glossary and Conventions 3-23 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 3-24 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 PART 2. SPP PROTOCOL _____________________ SECTION 4. SPP LOGICAL OPERATIONS . . . . . . . . . . . . . . . . . . 4-1 4.1 Logical System Description . . . . . . . . . . . . . . . . . . . . 4-1 4.2 Description of Logical Operations . . . . . . . . . . . . . . . . 4-2 4.3 Mandatory Requirements . . . . . . . . . . . . . . . . . . . . . . 4-5 4.4 Logical System Definition . . . . . . . . . . . . . . . . . . . . 4-6 4.5 I/O Processes . . . . . . . . . . . . . . . . . . . . . . . . . 4-11 4.5.1 I/O Process Parameter Requirements (Mandatory) . . . . . . . 4-11 4.5.2 I/O Process Sense Data (Mandatory) . . . . . . . . . . . . . 4-12 4.5.3 SPP Identification . . . . . . . . . . . . . . . . . . . . . 4-12 4.5.3.1 Initiating Controller Identification (Optional) . . . . 4-13 4.5.3.2 SPP Address for a Port (Mandatory) . . . . . . . . . . . 4-13 4.5.3.3 Logical Units (Mandatory) . . . . . . . . . . . . . . . 4-13 4.5.3.4 Target Routines (Optional) . . . . . . . . . . . . . . . 4-13 4.6 Queued I/O Processes (Mandatory) . . . . . . . . . . . . . . . . 4-14 4.6.1 Untagged I/O Processes (Mandatory) . . . . . . . . . . . . . 4-14 4.6.2 Tagged I/O Processes (Optional) . . . . . . . . . . . . . . 4-15 4.6.3 Concurrent I/O Processes Execution . . . . . . . . . . . . . 4-19 4.7 Programmable Operating Definition (Parallel) (Optional) . . . . 4-19 4.8 I/O Process Termination . . . . . . . . . . . . . . . . . . . . 4-20 4.8.1 Normal I/O Process Termination . . . . . . . . . . . . . . . 4-20 4.8.2 Abnormal I/O Process Termination . . . . . . . . . . . . . . 4-21 4.8.2.1 Initiating Controller Caused Termination . . . . . . . . 4-21 4.8.2.2 Target Controller Caused Termination . . . . . . . . . . 4-21 4.9 Logical Unit Reservation Termination (Mandatory) . . . . . . . . 4-21 4.10 Path Group Operations (Optional) . . . . . . . . . . . . . . . 4-21 4.10.1 Single Path Mode . . . . . . . . . . . . . . . . . . . . . 4-22 4.10.2 Multiple Path Mode . . . . . . . . . . . . . . . . . . . . 4-22 4.10.3 Single Path Status . . . . . . . . . . . . . . . . . . . . 4-22 4.10.4 Multiple Path Status . . . . . . . . . . . . . . . . . . . 4-22 4.11 Assignment Termination (Optional) . . . . . . . . . . . . . . . 4-22 4.12 Path Group Termination (Optional) . . . . . . . . . . . . . . . 4-22 SECTION 5. SPP I/O PROCESS STRUCTURE . . . . . . . . . . . . . . . . . 5-1 5.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.1.1 Command Set Implementation Requirements (Mandatory) . . . . . 5-2 5.1.2 Reserved (Mandatory) . . . . . . . . . . . . . . . . . . . . . 5-2 5.1.3 Command Descriptor Block . . . . . . . . . . . . . . . . . . . 5-3 5.1.4 Operation Code (Mandatory) . . . . . . . . . . . . . . . . . . 5-5 5.1.5 Logical Block Address . . . . . . . . . . . . . . . . . . . . 5-5 5.1.6 Transfer Length . . . . . . . . . . . . . . . . . . . . . . . 5-6 5.1.7 Command Parameter Data Length . . . . . . . . . . . . . . . . 5-7 5.1.8 Command Response Data Length . . . . . . . . . . . . . . . . . 5-7 5.1.9 Control Field (Mandatory) . . . . . . . . . . . . . . . . . . 5-8 5.1.9.1 Link Bit (Mandatory) . . . . . . . . . . . . . . . . . . . 5-8 5.1.9.2 Flag Bit (Mandatory) . . . . . . . . . . . . . . . . . . . 5-9 5.2 Status (Mandatory) . . . . . . . . . . . . . . . . . . . . . . . . 5-9 5.2.1 Status Codes (Mandatory) . . . . . . . . . . . . . . . . . . 5-11 5.2.2 Status Code Reporting Priority (Mandatory) . . . . . . . . . 5-13 Part 2. SPP Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 5.3 Contingent Allegiance Condition (Mandatory) . . . . . . . . . . 5-14 5.4 Extended Contingent Allegiance Condition (Optional) . . . . . . 5-15 5.5 Asynchronous Event Notification (Mandatory) . . . . . . . . . . 5-16 SECTION 6. SPP INFORMATION PACKET STRUCTURE . . . . . . . . . . . . . 6-1 6.1 Information Packet Structure . . . . . . . . . . . . . . . . . . . 6-1 6.1.1 Interface Control Fields (Mandatory) . . . . . . . . . . . . . 6-2 6.1.2 Interface Logical Elements (Mandatory) . . . . . . . . . . . . 6-6 6.1.2.1 Message Interface Logical Element . . . . . . . . . . . . 6-8 6.1.2.2 Command Descriptor Block Interface Logical Element . . . . 6-8 6.1.2.3 Command Parameter Data Interface Logical Element . . . . . 6-8 6.1.2.4 Command Response Data Interface Logical Element . . . . . 6-8 6.1.2.5 Logical Block Data Interface Logical Element . . . . . . . 6-9 6.1.2.6 Status Interface Logical Element . . . . . . . . . . . . . 6-9 6.1.2.7 Autosense Interface Logical Element (Optional) . . . . . . 6-9 SECTION 7. SPP I/O PROCESS CONTROL . . . . . . . . . . . . . . . . . . 7-1 7.1 Messages (Mandatory) . . . . . . . . . . . . . . . . . . . . . . . 7-1 7.1.1 ABORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6 7.1.2 ABORT I/O PROCESS . . . . . . . . . . . . . . . . . . . . . . 7-6 7.1.3 BUS DEVICE RESET . . . . . . . . . . . . . . . . . . . . . . . 7-7 7.1.4 CLEAR QUEUE . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 7.1.5 I/O PROCESS COMPLETE . . . . . . . . . . . . . . . . . . . . . 7-7 7.1.6 EXTENDED MESSAGE REJECT . . . . . . . . . . . . . . . . . . . 7-8 7.1.7 INITIATE RECOVERY . . . . . . . . . . . . . . . . . . . . . . 7-9 7.1.8 INVALID BUS PHASE DETECTED (Parallel) . . . . . . . . . . . . 7-9 7.1.9 INVALID INFORMATION PACKET . . . . . . . . . . . . . . . . . 7-10 7.1.10 LINKED COMMAND COMPLETE . . . . . . . . . . . . . . . . . . 7-11 7.1.11 LINKED COMMAND COMPLETE (WITH FLAG) . . . . . . . . . . . . 7-12 7.1.12 MODIFY DATA POSITION . . . . . . . . . . . . . . . . . . . 7-12 7.1.13 PARITY ERROR (Parallel) . . . . . . . . . . . . . . . . . . 7-12 7.1.14 RELEASE RECOVERY . . . . . . . . . . . . . . . . . . . . . 7-13 7.1.15 RESEND PREVIOUS INFORMATION PACKET . . . . . . . . . . . . 7-13 7.1.16 SYNCHRONOUS DATA TRANSFER REQUEST (Parallel) . . . . . . . 7-14 7.1.17 SYNCHRONOUS PACKET TRANSFER REQUEST . . . . . . . . . . . . 7-16 7.1.18 TERMINATE I/O PROCESS . . . . . . . . . . . . . . . . . . . 7-18 7.1.19 TRANSFER READY . . . . . . . . . . . . . . . . . . . . . . 7-20 7.2 Command Processing Considerations and Exception Conditions . . . 7-21 7.2.1 Unit Attention Condition . . . . . . . . . . . . . . . . . . 7-21 7.2.2 Incorrect Initiating Controller Connection . . . . . . . . . 7-23 7.2.3 I/O Processes for an Invalid LUN or TRN . . . . . . . . . . 7-23 7.2.4 Parameter Rounding . . . . . . . . . . . . . . . . . . . . . 7-24 7.2.5 Unsuccessful I/O Process Termination Condition . . . . . . . 7-24 7.2.6 Reset Condition (Mandatory) . . . . . . . . . . . . . . . . 7-25 7.2.7 Unsuccessful Information Packet Transfer Condition . . . . . 7-26 7.2.8 Unexpected Disconnect Condition . . . . . . . . . . . . . . 7-26 7.2.9 Attention Condition (Parallel) . . . . . . . . . . . . . . . 7-26 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 4. SPP LOGICAL OPERATIONS __________________________________ This section contains the logical system description of SPP. All I/O processes are accomplished by transferring information packets com- posed of interface logical elements. Initiating controllers and target con- trollers interpret the interface logical elements. Interface logical elements are messages, command descriptor blocks, command parameter data (additional data required for some commands), command response data (data not from logical blocks), logical blocks, autosense, and status. Initial information packet transfers on a SPI bus, are in asynchronous data transfer mode to perform synchronous data transfer negotiation only. For serial interface implementations, all transfers are in synchronous data transfer mode. 4.1 LOGICAL SYSTEM DESCRIPTION _______________________________ This section describes the logical system for an SPP environment to perform device-independent activity using one or more SPP busses. Figure 4-2 on page 4-10 shows the relationship of several terms from the glossary related to the mimimum logical system. The SCSI-3 Packetized Protocol, as viewed by initiating controllers and target controllers, is shown in Figure 4-1 on page 4-2. The initiating con- troller prepares an information packet and sends it to the target controller using the services of a transport layer. The target controller receives the complete information packet, interprets it, and prepares a response in the form of an information packet. It sends the information packet in the same manner as the initiating controller. The initiating controller receives a complete information packet as a result of the transmission. This exchange of information packets continues until an I/O process is com- plete. Information packets for multiple I/O processes may be multiplexed by both the initiating controller and the target controller to the same or dif- ferent devices. Section 4. SPP Logical Operations 4-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | INITIATING CONTROLLER TARGET CONTROLLER | | | | +-----+ +-----+ | | | B | | B | | | | U | SPP | U | | | | F |<------INFORMATION PACKETS ------>| F | | | | F | | F | | | | E | | E | | | | R | | R | | | +---A-+ +-A---+ | | | | | | | | | | | | | | | +<-----+ +--------+ | | | | | | | | | | +-----+ | | +-->+ | | | | | | | | | | | | | | | | | | | | | | | | | +-V-----+ SPP PORTS +--V----+ | | | | | | | T | | T | | | | | | | | R | | R | | | | | +--V----+ A L |<---------------->| A L +----V--+ | | | T | N A | | N A | T | | | | R | S Y | SSI AND/OR SPI | S Y | R | | | | A L | P E | BUS(BUSSES) | P E | A L | | | | N A | O R | | O R | N A | | | | S Y |<------------------------------>| S Y | | | | P E | T | | T | P E | | | | O R |------+ +------| O R | | | | R | | R | | | | T | | T | | | +-------+ +-------+ | | | +---------------------------------------------------------------------------+ Figure 4-1. SPP High Level Protocol 4.2 DESCRIPTION OF LOGICAL OPERATIONS ______________________________________ An I/O process consists of a minimum of one information packet. Such an I/O process is concerned only with messages, such as BUS DEVICE RESET, which do not require a response from the target controller as part of an I/O process. Most I/O processes consists of at least two information packets. One infor- mation packet is sent from the initiating controller to the target controller to request some function(s) be performed. The target controller responds at completion of the function with an information packet indicating the status of the request(s). I/O processes which transfer logical blocks may require many information packets. The form of the request to perform a function is called a command descriptor block. Each command descriptor block is fixed length. Some commands need to transfer more data than can fit into the command descriptor block. This 4-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 additional data is called command parameter data. It is variable in length with the length specified in the command descriptor block. For commands which do not transfer logical block data, the target controller checks the command descriptor block and the command parameter data, if any. If they are correctly formed with valid values, the target controller exe- cutes the command. When execution is complete and successful, the target controller forms an information packet containing the status of the command and a command completion message (there are three). The information packet, when received at the initiating controller is checked and the I/O process parameters are updated. An alternative form of a command has a command descriptor block with no command parameter data, but it requires that the target controller return data, other than logical block data, as command response data. Execution is similar to the command description above. For commands which transfer logical block data, more than two information packets may be needed. For write-type commands, the initiating controller places the command descriptor block and possibly some of the logical block data in the first information packet and sends it. The target controller checks the command descriptor block as before. If it is correctly formed, the target controller can begin to process the logical block data, if present in the information packet. Meanwhile, the initiating controller may have filled up additional informa- tion packets and sent them, up to the limit agreed upon between the two logical elements. The target controller overlaps receipt of additional information packets with processing of each information packet. The target controller informs the initiating controller as the information packets are processed so that additional packets, if any, can be transferred. When all data has been transferred, the target controller finishes processing the data as specified by the MODE SELECT parameters and the command descriptor block. The status and command completion message are placed in an information packet and sent to the initiating controller. The I/O process is complete. The initiating controller can link several commands together to form larger I/O processes and place them in one or more information packets. I/O proc- esses with linked commands are treated as a unit by the target controller and the initiating controller. If, as is occasionally the case, the command descriptor block contains an error, the command is not executed. Any interface logical elements following the command descriptor block are not processed (i.e., treated as not having been received). Additional information packets for the I/O process are not processed. Detecting the error requires the target controller to terminate the I/O process and prepare sense data to identify the error. The error condition indicated above requires no recovery action which involves the target controller. This condition is called a contingent alle- giance condition. If the condition is reported using an autosense informa- tion logical element, the condition is immediately cleared with successful Section 4. SPP Logical Operations 4-3 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 transfer of the information packet which transfers the status and autosense interface logical elements (ILEs). The I/O process is terminated. If the target controller does not transfer autosense, the target controller prepares an information packet with status to indicate an error and a command completion message. The information packet, without an autosense ILE, is sent to the initiating controller. The I/O process is terminated but the contingent allegiance conditions remains in effect. If the target controller sends only status it shall preserve the sense data for possible retrieval by the initiating controller. The initiating con- troller may form an new untagged I/O process with the first command being a REQUEST SENSE command and send it to the target controller. The target con- troller sends the sense data in response to the REQUEST SENSE command and clears the contingent allegiance condition. The initiating controller may also ignore the status and send some other command which causes the target controller to clear the contingent allegiance condition and the sense data. If the error is more significant and the target controller determines that the error requires a recovery process involving both the initiating con- troller and the target controller, the condition is called an extended con- tingent allegiance. In addition to the status and autosense data, a special message informs the initiating controller of this condition. The target con- troller restricts access to the logical unit until the initiating controller releases it from extended contingent allegiance by sending the target con- troller another special message. If an error is detected outside the bounds of an active I/O process, the target controller uses a protocol called asynchronous event notification to transfer appropriate sense data to affected initiating controllers. Asyn- chronous event notification may result in extended contingent allegiance. The protocol for notification and exit is similar to the preceding example. There are different kinds of data transferred in information packets which are never all transmitted in the same information packet. These data are called interface logical elements. The interface logical elements are command descriptor blocks, status, messages, command parameter data, command response data, autosense, and logical block data. As described above, a target controller may have multiple ILEs from one or more information packets available for an I/O process from an initiating con- troller befor starting or during execution of an I/O process. Additionally, the target controller may permit one I/O process from each other initiating controllers. This is called untagged queuing. The depth of the queue is implementation dependent. The maximum depth shall not exceed one per initi- ating controller per logical unit or target routine. The minimum depth is one I/O process allowed in the target controller at a time. The target con- troller may execute these I/O processes in any order is deems appropriate. The second level of queuing requires the initiating controller to assign a code or a tag to each of its I/O processes for each logical unit. If the target controller has implemented this level of queuing, the target con- troller may have several I/O processes for the same initiating controller in 4-4 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 the I/O process queues for the same logical unit as well as I/O processses from other initiating controllers. This is called tagged queuing. This section has described, generally, the major elements of SPP I/O process flow. See the glossary for complete definitions of the terms introduced above. Details are covered in the following sections. Interoperability con- siderations with SPP logical elements are described below. The specific rules governing execution of I/O processes is discussed in subsequent sections. Some detailed examples are found in -- Heading 'APPA' unknown --. 4.3 MANDATORY REQUIREMENTS ___________________________ Mandatory requirements for logical operation placed on initiating controllers and target controllers include: 1) All ports shall implement an active initiator mode and an active target mode (i.e., dynamic switching of the port mode). 2) All SPP ports shall implement synchronous data transfer. (Serial Inter- faces.) Synchronous data transfer mode is the only transfer mode on the serial interface. (Parallel Interfaces.) Each SPI port shall negotiate for and be granted synchronous data transfer mode. All transfers, other than during synchronous negotiation shall be in synchronous data transfer mode. 3) (Parallel Interfaces.) A parallel SPI bus shall not have an intermix SPI ports of unequal DATA BUS widths. 4) (Parallel Interfaces.) All SPI ports which implement a DATA BUS width greater than one byte shall perform all information transfers at full bus width. 5) A port which normally acts as an initiator, when selected, shall enter target mode. An initiating controller shall declare itself as a processor device class in response to the INQUIRY command. 6) Initiating controllers shall respond correctly to asynchronous event notification (always enabled). 7) Target controllers shall implement initiator mode on each port to select initiators, to acquire the INQUIRY data to determine its principal initiating controllers, and to support asynchronous event notification. Events not occurring in the bounds of an I/O process are reported when they occur. 8) (Parallel Interface.) Initiating controllers and target controllers shall perform a synchronous data transfer negotiation as the first set of informa- tion transfers after any event which may make the synchronous negotiation invalid. The default state of a port at power-on shall be asynchronous data transfer mode. The state of a port after a reset event shall be asynchronous data transfer mode. 9) Target controllers shall implement the mandatory commands for both the common commands in SPP and for the implemented device class (in SDCS). Section 4. SPP Logical Operations 4-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 Within each command, all function defined as mandatory shall be implemented. This provides a minimum functional base for all implementations of a device class. 10) Logical elements shall implement untagged queuing. Tagged queuing is optional. 4.4 LOGICAL SYSTEM DEFINITION ______________________________ A logical system consists eighteen (19) items. Items 1) through 14) are man- datory; items 15) thorugh 19) are optional. 1) a minimum logical system consists of two SPP ports and one SPP bus con- necting them. 2) each SPP port is capable of operating in initiator mode (called an initi- ator) on its SPP bus. 3) each SPP port is capable of operating in target mode (called a target) on its SPP bus. 4) the initiator and target in Items 2 and 3 above, attach to the same SPP bus and are active in their respective modes during a connection between them (i.e., not the same port); the two ports may reverse modes for each con- nection. 5) the logical element attaching an SPP device which principally starts I/O processes is called an initiating controller. An initiating controller con- trols one or more ports per item 2. The same ports are used for target mode per item 3. 6) the logical element attaching an SPP device which principally receives and executes I/O processes is called a target controller. A target controller controls one or more ports per item 3. The same ports are used for initiator mode per item 2. NOTE: The names given to the logical elements attaching an SPP device do not prevent any SPP device from using all functions of SPP. The word "principally" in Items 5 and 6 implies this. Thus, a copy manager, acting principally as a target controller, may act as an initiating controller and use all defined functions of the commands and the logical system to perform a copy operation. 7) each port has an SPP address unique to the SPP bus on which it attaches. (Parallel Interfaces.) The SPP address translates to the physical SPI ID on the SPI bus. The SPI ID may be the same or different for each port when each port attaches to a different SPI bus. 8) each port is assigned a port number by its controlling logical element. The port number is unique within each logical element. 9) each target controller has one or more logical units each identified by a unique logical unit number (LUN). LUNs are contiguous beginning at zero. 4-6 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 10) each target controller has zero or more target routines each identified by a target routine number (TRN). TRNs are contiguous beginning at zero. 11) the extent of a logical system, from a target controller, is the set of all initiating controller/initiator combinations attached, through one or more SPP busses, to the target controller and from which a connect has been made. For an initiating controller, the extent of a logical system is the set of all logical units and target routines to which a connect has been made on one or more SPP busses. 12) For initiating controllers having access to a logical unit, access can be restricted to certain extents within some logical unit types, based on device class. Also, access may be temporarily restricted for a complete logical unit. These reservation functions provide the lowest level of restriction to information within a logical unit. There is no equivalent reservation func- tion for target routines. 13) Each initiating controller is assigned an initiating controller ID. An initiating controller ID (ICID) must be unique in a logical system. An identifier consisting of a ICID, an initiating controller port number, an initiator SPP address, a target controller SPP address, a target controller port number, and a LUN or TRN, defines a path when the relationship is estab- lished as the result of a connect started by an initiating controller to a logical unit or target routine. This is called an implicitly named path. That is, the initiating controller has the complete name of the path, but the target controller does not. The port numbers are transferred as part of each complete I/O process. No path exists between a LUN or TRN and an initiating controller unless the LUN or TRN is the object of a connect started by that initiating controller to the LUN or TRN. An implicitly named path is in an ungrouped state. When a path is in the ungrouped state, each I/O process is limited to operation on the path where the connect was made. This is called single path mode. Each initiator con- necting with a target controller on any port must be considered as attached to a unique initiating controller until the transfer of an ICID from the ini- tiating controller occurs. 14) All communication between initiating controllers and target controllers shall be in the form of information packets, except primitive signals as defined for each SPP bus. 15) An initiating controller transfers its ICID using a defined command between the logical elements. The implicitly named path becomes an explic- itly named path. An initiating controller connects with and transfers its ICID by a command to each logical unit or target routine with which it needs to define an explicitly named path. The LUN or TRN used with each command must be valid for the target controller. The logical unit need not be ready or installed (e.g., powered off but cabled or not cabled). The initiating controller is not required to transfer its ICID on all available physical paths between the initiating controller and the LUN or TRN, but only on those Section 4. SPP Logical Operations 4-7 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 paths which it intends to use for additional SPP functions (Items 16 thorugh 19). Once paths are named, the target controller can distinguish which paths belong to which initiating controllers. An explicitly named path is initially in an ungrouped state. I/O processes are handled in the same manner as an implicitly named path unless additional agreements are reached between the initiating controller and the target con- troller as defined below. 16) An identifier, consisting of an ICID and either a LUN or TRN in the same target controller, represents one logical path. A logical path consists of one or more explicitly named paths or exactly one implicitly named path. The paths in a logical path are initially in an ungrouped state. (See Item 13.) The set of paths available in a logical path from an initiating controller to any one logical unit or target routine may be determined from the results of the INQUIRY command response data provided the command response data is unique to each logical unit or target routine. 17) A set of ungrouped explicitly named paths in a logical path is estab- lished as a path group through a command from the initiating controller using any one of the paths in the logical path. This set of paths, a logical path, is called a path group. Establishing a path group is the mechanism for ena- bling multiple path operations in logical system. Including a path in a path group does not restrict access to the logical unit or target routine from any other path. When establishing a path group, the initiating controller identifies where status leading to a contingent allegiance or extended contingent allegiance is reported. Any status which does not result in contingent allegiance may be sent over any path in the path group. The choices are single path status mode and multiple path status mode. The condition may be altered by dis- banding the group and establishing the group with the alternate choice. A path may be added to an established group at a later time by a command from the initiating controller on that path. A path may be removed from an established path group by a command from the initiating controller on that path. Once a path group is established, the extended functions of assignment (Item 19) and multiple path operation may be used. The inverse of establishing a path group is to disband a path group. A path group may be explicitly disbanded by a command from the initiating controller along any one path in the path group. A path group is implicitly disbanded when the last path is removed from an established path group using a remove path function rather than a disband function. 18) Any logical unit or target routine is initially available to receive I/O processes from any initiating controller attached to a target controller. This use privilege is extended whether the path is explicitly named, implic- itly named, and whether for explicitly named paths, the path is grouped or ungrouped. 4-8 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 The two functions of assignment are: 1) assign this LUN or TRN to the path group on which the command was received, or 2) add assignment of this LUN or TRN for another established path group. The inverse of assign is unassign. Use privileges may be unassigned for any path group to which assignment currently exists from any path for which assignment currently exists. Assignment may be transferred from one initi- ating controller to another without passing through a state where no assign- ment exists. 19) Controlled access is the name given to the function which breaks an assignment if some error or failure occurs in an initiating controller which currently has assignment. Breaking assignment may be temporary or permanent, but it must be controlled, as are other functions which can lead to reli- ability, availability, and data integrity problems. Assignment permits use privileges only through assigned path groups. Con- trolled access permits access outside the bounds of assigned path groups. The mechanism to prevent deliberate or accidental loss of assignment pro- tection is the control access function, enabled by a password and checked by the affected target controller. The control access command has three functions: 1) establish a password in a target controller. 2) general unassign. 3) request temporary unassignment. A password is established by an initiating controller having assignment. The password is not reported by a target controller on any path. The target con- troller checks its established password, if any, against password supplied by the control access command function from an initiating controller not having assignment. If the target controller has an established password and it matches the pass- word with the command, the control access command and any commands linked to it are executed, if possible. The mechanism by which the unassigned initi- ating controller acquires the correct password is not defined. Section 4. SPP Logical Operations 4-9 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | | | INITIATING CONTROLLER | | ICID | | | | INITIATING CONTROLLER PORT NUMBER | | SPP PORT IN INITIATOR MODE | | INITIATOR | | | | SPP ADDRESS | | SPI ID (PARALLEL INTERFACE) | | | | +-----+ +-----+ | | | | INFORMATION PACKETS | | | | | P | | P | | | | O |<-------------------------->| O | | | | R | | R | | | | T | SSI OR SPI BUS | T | | | | | | | | | +-----+ +-----+ | | | | SPI ID (PARALLEL INTERFACE) | | SPP ADDRESS | | | | TARGET | | SPP PORT IN TARGET MODE | | TARGET CONTROLLER PORT NUMBER| | | | TARGET CONTROLLER | | LOGICAL UNIT | | LU IS UNASSIGNED | | RESERVED/NOT RESERVED | | LUN | | | | | | PATH = ICID || | | INITIATING CONTROLLER PORT NUMBER || | | INITIATOR SPP ADDRESS || | | TARGET SPP ADDRESS || | | TARGET CONTROLLER PORT NUMBER || | | LUN | | | | LOGICAL PATH = ICID || LUN | | PATH IS IMPLICITLY NAMED | | PATH IS IN THE UNGROUPED STATE | | PATH GROUP IS NOT ESTABLISHED | | PATH STATUS IS IMPLICITLY NAMED PATH | | | | SINGLE PATH STATUS MODE | | NO PASSWORD EXISTS | | | | | | | +---------------------------------------------------------------------------+ 4-10 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 Figure 4-2. Minimum Logical System Attributes 4.5 I/O PROCESSES __________________ Consider the simplified system shown in Figure 4-3 where an initiating con- troller and target controller communicate on a single SPP bus to execute an I/O process. +---------------------------------------------------------------------------+ | | | ------------------------- -------------------------| | |INITIATING| | INITIATOR|<----------------| TARGET | | TARGET || | |CONTROLLER| | TRANSPORT| SPP BUS | TRANSPORT| |CONTROLLER|| | | | | LAYER |---------------->| LAYER | | || | ------------------------- -------------------------| | | +---------------------------------------------------------------------------+ Figure 4-3. Simplified SPP System SPP requires that both the initiating controller and the target controller involved in an I/O process retain status about its operation and the ports with which it communicates. 4.5.1 I/O PROCESS PARAMETER REQUIREMENTS (MANDATORY) For logical elements, there are several kinds of parameters that each shall maintain: 1) (Parallel Interfaces.) Synchronous transfer negotiation agreement between the ports capable of being used during the I/O process. 2) (Serial Interfaces.) Service parameters of the serial interface and for each SPP device selected for an initial connection. 3) Path names and path group agreements, assignment, and passwords for all logical units and target routines, including the no agreement states of these. 4) A queue of information packet buffer space(s) to be used for holding information packets. The information packets may not be associated with the an I/O process until later. Each information packet may belong to an active I/O process, a queued I/O process, or it may be used to establish a new I/O process. 5) A queue of I/O processes which are not yet in the active I/O process state and the associated information packet(s). Support for untagged I/O processes is mandatory; support for tagged I/O processes is optional. The difference in a logical element is the complexity of queue management. 6) A queue of active I/O processes and the state of each I/O process. The state of each active I/O process requires several elements: which information Section 4. SPP Logical Operations 4-11 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 packets have been transferred, the logical order of the information packets, which ILEs have been processed, a status field to hold the status for each I/O process, an indication of the current state of data transfer for each command, if any, an area to receive or prepare sense data for the I/O process should it end with contingent allegiance or extended contingent allegiance, and a means to tie the sense data to the correct portion the I/O process. 7) A queue of outgoing information packets pending transmission for each active I/O process. 8) A queue of information packets which have been transmitted sufficient to meet the retransmission requirements of the synchronous packet transfer nego- tiation agreement for each I/O process. These shall be identified to their active I/O process. As the ILEs for an I/O process are being processed between the initiating controller and the target controller these parameters must be updated. The update for received information packets is made when the information packet is processed; this may not be at the time it is received. The update for information packets sent is made as each information packet is transferred. The state of an I/O process may appear different at the initiating controller and the target controller as a result of the potential difference in time for I/O process updates. 4.5.2 I/O PROCESS SENSE DATA (MANDATORY) For each target controller, the target controller shall maintain the states of each logical unit and target routine and maintain the minimum data as required by the device class and the device type implemented. This minimum data is called sense data. The format of the mandatory portion is specified with the REQUEST SENSE command. Sense data is to be kept current with the state of the logical unit, target routine, and target controller. As events occur, the target controller shall update the sense data. The target controller shall be prepared to transmit sense data as a response to a REQUEST SENSE command or as autosense for any status leading to contingent allegiance or extended contingent allegiance. 4.5.3 SPP IDENTIFICATION There are three levels of addresses within SPP: the initiating controller identification (ICID), the SPP address for a port, and the logical unit number or target routine number. 4-12 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 4.5.3.1 Initiating Controller Identification (Optional) The initiating controller identification (ICID) is a unique name or tag given to each initiating controller in a logical system that intends to participate in multiple path operations (See Logical System Definition, items 13, and 15-19). By communicating this value to each target controller, the target controller can determine which physical paths belong to the same initiating controller. Transfer of the ICID is the first step in enabling multiple path operations. 4.5.3.2 SPP Address for a Port (Mandatory) A SPP port responds to one SPP address on the SPP bus. Generally the logical element provides a means to select one of the 256 available addresses (0 to 255). Only a maximum of 255 other ports may be selected since the selecting port uses one SPP address for itself. Each port on the SPP bus is assigned an unique address. (Parallel Interfaces.) The maximum SPP address/SPI ID combination is limited to the range 0 to (8 * bus width in bytes - 1). This address is converted to the SPI ID during bus arbitration and selection of SPP devices. Normally, the SPP port address is set when the SPP busses are configured and it remains static thereafter. Some initiating controllers and target con- trollers provide vendor specific means to alter this address at other times. 4.5.3.3 Logical Units (Mandatory) Each target controller shall have a minimum of one logical unit and first or only logical unit number shall be zero. Logical unit numbers shall be con- tiguous through the maximum number of logical units supported by the target controller. There can be a maximum of 256 logical units. These logical units are usually mapped directly to peripheral devices, but they may be a portion of a peripheral device or may comprise multiple peripheral devices. An initiating controller can determine whether a target controller implements a logical unit by sending an INQUIRY command to the logical unit and exam- ining the returned peripheral qualifier and peripheral device type. Logical unit(s) are defined only for the target role of each logical element. Initiating controllers implement a target role and shall define one or more logical unit numbers as any other principal target controller does. 4.5.3.4 Target Routines (Optional) An optional feature of SPP permits each target controller to have one or more target routines, beginning with target routine number zero. Target routine numbers shall be contiguous through the maximum number of target routines supported by the target controller. There can be a maximum of 256 target routines. These target routines are processes that execute directly in the target controller and are not associated with a particular logical unit or peripheral device. Section 4. SPP Logical Operations 4-13 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 Target routines are principally intended to return information about the target controller. 4.6 QUEUED I/O PROCESSES (MANDATORY) _____________________________________ There are two methods for specifying the type I/O process: untagged (manda- tory) and tagged (optional). The nature of the serial interface makes it necessary to be able to receive and store information packets before they are processed. Therefore, as a minimum, untagged queuing is a fundamental requirement for implementations using the serial interface. This is carried over as a requirement for the parallel interface to aid interoperability. Untagged I/O processes allow a target controller to receive one I/O process from each initiating controller for each logical unit or target routine. Tagged I/O processes allow a target controller to accept multiple I/O proc- esses from each initiating controller for each logical unit. Tagged I/O processes for target routines are not permitted. A target controller may be capable of both types of I/O processes, but only one method may be used at a time per logical unit/initiating controller combination. Information packets permit the transfer of more than one ILE per connection for an I/O process. ILEs from one or more information packets may be queued in the target controller just as they may be queued in the initiating con- troller. That is, the entire initiating controller portion of an I/O process, if permitted by the information packet formation rules, may be transferred to the target controller in one set of information packets and queued in the target controller. The initiating controller follows the progress of the I/O process by processing status, logical block data, command response data, autosense, and messages received from the target controller in information packets. If additional information packets are required, the initiating controller sends them to the target controller at the appropriate time. For implementations supporting only untagged I/O processes, the ILEs for the initiating controllers portion of an entire I/O process may be queued at the target controller. For some I/O processes, only the target controller status and associated messages for each command are required to be returned from the target controller in one or more information packets if there are no errors. If there is an error which causes termination of an I/O process, all of the remaining unprocessed ILEs from the initiating controller for the I/O process are purged from the active I/O process queue. 4.6.1 UNTAGGED I/O PROCESSES (MANDATORY) Untagged I/O processes allow a target controller to receive one I/O process from each initiating controller for each logical unit or target routine in the target controller. One or more I/O processes , each from a different initiating controllers may be active. Each untagged I/O process forms an H_C_x nexus. 4-14 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 The target controller shall be able to have at least one active I/O process. Other I/O processes may then be held in the queued I/O process queue waiting for activation. Optionally, the target controller may permit other combina- tions of active I/O processes which might include one active I/O process per logical unit and target routine, or more than one active I/O process per logical unit or target routine. The specific maximum limits for I/O processes in the target controller are that the target shall not have active or queued more than a total of one I/O process per initiating controller per logical unit or target routine. For a logical system of two initiating controllers and one target controller with two logical units, each initiating controller can have one I/O process in the target controller for each logical unit or target routine. The target con- troller may not implement a queue depth to actually permit the four I/O proc- esses to be active or queued. (See QUEUE FULL status.) Only one command for each H_C_x nexus shall be executed per initiating con- troller at a time and in the order received. If the target controller has no space to store additional ILEs, for an existing active or queued I/O process, the target controller shall return QUEUE FULL status to for the new informa- tion packet. The information packet may be resent at a later time. An initiating controller may attempt to start or add to an I/O process any time the BUS FREE phase exists. The H_C_x nexus sufficiently specifies the relationship so that the target controller can reconnect to the initiating controller for the I/O process. It is the responsibility of the initiating controller to assure that only one such I/O process is issued at any time. If the initiating controller attempts to establish a nexux for a second untagged I/O process, the target controller shall return QUEUE FULL status to the new I/O process. That is, for untagged queuing, the maximum depth for a single initiator/target con- troller function is one active or queued I/O process. If the initiating con- troller attempts to send too many information packets for the untagged I/O process, the target controller shall return QUEUE FULL status to the new I/O process. In either case, the initiating controller may attempt to send the information packets at a later time. Deferred errors are normally related to an I/O process that has already com- pleted. The target controller shall not retain the queue tag value assigned to the original I/O process. 4.6.2 TAGGED I/O PROCESSES (OPTIONAL) Tagged I/O processes allow a target controller to accept multiple I/O proc- esses from the same or different initiating controllers until the logical unit's queued I/O process queue is full. Tagged I/O processes shall not be implemented for target routines. Each I/O process forms an H_C_L_Q nexus. Only one command for each H_C_L_Q nexus shall be executed at a time and in the order received. If the target controller has no space to store a new information packet for an existing active or queued I/O process, the target Section 4. SPP Logical Operations 4-15 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 controller shall return QUEUE FULL status to for the new information packet. The information packet may be resent at a later time. Processing tagged I/O processes may be temporarily disabled internal to the target controller during certain initialization periods or to control internal resource utilization. During these periods the target shall return QUEUE FULL status. Tagged queuing may also be disabled thourgh the MODE SELECT command on an individual logical unit basis. A target controller that does not support tagged queuing (e.g., not implemented, disabled by the DQue bit in the control mode page) shall respond to any tagged I/O process with an INVALID INFORMATION PACKET message. The I/O process is not accepted by the target controller. The initiating controller may convert the I/O process to an untagged I/O process or it may wait for or attempt to change the state of the target controller for the logical unit. The queued I/O process queue is setup by the target controller to provide independent support for each logical unit. Target routines shall not accept a tagged I/O process. Initiating controllers may add I/O processes to or delete I/O processes from their portion of the queued I/O process queue. When adding an I/O process, the initiating controller may specify fixed order of execution, allow the target to define the order of execution, or specify that the I/O process is to be executed next. Target controllers shall imple- ment all of these queue management functions, if tagged I/O processes are supported. The initiating controller uses the interface control prefix fields to specify a unique H_C_L_Q nexus for each I/O process. The H_C_L_Q nexus allows the target controller to reconnect to an initiating controller for a specific I/O process. An initiating controller may have several I/O processes queued or active to the same or different logical units as long as each has a unique nexus. A set of linked commands is a single I/O process, and each informa- tion packet is assigned the same queue tag value. The target controller shall be able to have at least one active I/O process. Other I/O processes may then be held in the queued I/O process queue waiting for activation. Optionally, the target controller may permit other combina- tions of active I/O processes which might include one active I/O process per logical unit, or more than one active I/O process per logical unit, etc. The specific maximum limits for I/O processes in the target controller are that the target shall not have active or queued I/O processes with duplicate tags per initiating controller per logical unit. For a logical system of two initiating controllers and one target controller with two logical units, each initiating controller can have 256 I/O processes in the target controller for each logical unit. The target controller may not implement a queue depth to actually permit the 1024 I/O processes to be active or queued. (See QUEUE FULL status.) Each tagged I/O process specifies type of I/O process to be associated with the tag. The choices are simple, ordered and head of queue. In the examples that follow, HOQ-n means an I/O process with head of queue tag; Simple-n means an I/O process with a simple queue tag; Ordered-n means an I/O process 4-16 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 with an ordered queue tag. In the case of Simple-n I/O processes, no exe- cution order is implied in the example sequences. For each logical unit when only only simple queued I/O processes are used, the target controller may execute the I/O processes for all initiating con- trollers in any order within the constraints of the queue management algo- rithm specified in the control mode page parameters. If ordered queuing is used, the target shall execute the I/O processes in the order received independent of initiating controller. That is, only one ordered I/O process shall be executed per logical unit. All I/O processes received using simple queuing prior to an I/O process received using ordered queuing, regardless of initiating controller, shall be executed before the I/O process with the ordered queue tag. All I/O processes received with an simple queue tag after the last I/O process received with an ordered queue tag, regardless of initiating controller, shall be executed after termination of that I/O process with the ordered queue tag. If at least one ordered I/O process is received after one or more simple I/O processes, execute all simple I/O processes before executing the first of a new set of ordered I/O processes. The queue sequence is (Simple-1, ..., Simple-n, Ordered-1, Ordered-2). If simple I/O processes are received after one or more ordered I/O processes, execute all ordered I/O processes in the correct sequence before executing any simple I/O process in the new group. The queue sequence is (Ordered-1,..., Ordered-n, Simple-1, Simple-2). There may be multiple separate groups of simple and ordered I/O processes in the queued I/O process queue. The queue sequence may be (Ordered-x, Simple-x, Ordered-y, Simple-y, ....), where the "-x" and "-y" represent one or more I/O processes. The sequence may also start with Simple-x and then alternate. An I/O process received using a head of queue tag is placed as the first queued I/O process in the queued I/O process queue. An I/O process received with a head of queue tag shall not suspend any active I/O process for the logical unit. Consecutive I/O processes received with head of queue tag, and placed in the queued I/O process queue before any become active, are executed in a last-in-first-out order. If a head of queue I/O process is received and simple I/O processes are at the top of the queued I/O process queue, the resulting queue order is (HOQ-1, Simple-1, Simple-2, ...). If a head of queue I/O process is received and ordered I/O processes are at the top of the queued I/O process queue, the resulting queue order is (HOQ-1, Ordered-1, Ordered-2, ...). If a second head of queue I/O process is received, each sequence begins (HOQ-2, HOQ-1, ...). Unless there is a contingent allegiance or extended contingent allegiance condition for a logical unit, an I/O process received without a queue tag specified while there are any tagged I/O processes in the I/O process queues for the same initiating controller is an incorrect connection. That is, the initiating controller has failed to manage its queued and active I/O process queues correctly. An untagged I/O process shall only be directed to an active I/O process which has reported a status leading to contingent alle- giance or extended contingent allegiance while other tagged I/O processes are in the queued or active I/O process queues for a logical unit. Section 4. SPP Logical Operations 4-17 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 If two or more active I/O processes are active as a result of decisions made in the queuing algorithm and an error affects their normal completion, a con- tingent allegiance or extended contingent allegiance condition shall be gen- erated for all affected I/O proceses. If two I/O processes have pending reports of contingent or extended contingent allegiance to the same initi- ating controller for the same logical unit, the target controller shall report them serially. That is, a second error shall not be reported to the same initiating controller for the same logical unit while either a contin- gent allegiance or extended contingent allegiance is pending for the logical unit. During recovery from the error reported for an I/O process using a queue tag, the target controller returns BUSY status to other initiating controllers for the logical unit while the contingent allegiance or extended contingent alle- giance condition exists. During this time all I/O process execution in the active I/O process queue is suspended for the logical unit. No queued I/O processes are added to the active I/O process queue that affect the logical unit. All I/O processes used for recovery operations shall be untagged. The QIOPQ may be modified by removing all or selected I/O processes in the queue as part of the recovery procedure for extended contingent allegiance. One of two I/O process queue management options may be used after an active I/O process detects an error which results in contingent allegiance or extended contingent allegiance. The error recovery option is specified in the control mode page parameters. o The first recovery option is to continue execution of I/O processes remaining in the active and queued I/O process queues after the contin- gent allegiance or extended contingent allegiance condition has cleared. o The second recovery option clears the active and queued I/O process queues for the logical unit after the contingent allegiance or extended contingent allegiance condition has been cleared. When the queue is cleared because of this recovery option, a unit attention condition shall be generated for all other initiating controllers and the additional sense code shall be set to I/O PROCESSES CLEARED BY ANOTHER INITIATOR. (Update Command section? GRS) Several messages may be used to clear part or all of the command queue during the recovery process. For contingent allegiance, only one I/O process which includes at least one command can be executed. I/O processes containing only messages may be executed without destroying the preserved sense data. For extended contingent allegiance, several untagged I/O processes may be executed until the RELEASE RECOVERY message is executed at the target con- troller. Refer to the ABORT, ABORT TAG, BUS DEVICE RESET, and CLEAR QUEUE messages for details. Deferred errors are normally related to an I/O process that has already com- pleted. The target controller shall not retain the queue tag value assigned to the original I/O process. (add/revise for ASSIGN/UNASSIGN. GRS) 4-18 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 The TEST UNIT READY and INQUIRY commands are often sent as head of queue, since the information returned has no effect on the condition of the logical unit. The RESERVE and RELEASE commands should be sent as an ordered I/O process. Use of the head of queue or simple queue functions with these I/O processes could result in reservation conflicts when other queued I/O processes become active; such I/O processes are purged by the target controller as if they had never been received by reporting RESERVATION CONFLICT status to the initi- ating controller(s) for each affected I/O process. 4.6.3 CONCURRENT I/O PROCESSES EXECUTION The various options for processing untagged and tagged processes permit con- current execution of I/O processes within a target controller function under certain circumstances. The rules for concurrent processing are summarized in Figure 4-4 on page 4-20 4.7 PROGRAMMABLE OPERATING DEFINITION (PARALLEL) (OPTIONAL) ____________________________________________________________ This section applies only to initiating controllers and target controllers attached via a SPI bus. There is no alternative operating definition for SPP devices attached to a SSI bus. Some applications require that the operating definition of a logical unit be modified to meet the special requirements of a particular initiating con- troller. The program-controlled modification of the operating definition a logical unit is typically provided to allow operating systems to change the operating definition of more recently developed target controllers to one which is more compatible with the operating system. Invoking this function requires that the initiating controller and its initiators comply with the protocl of SPI after the change definition is complete. An initiating controller may request a list of the operating definitions that the target supports and descriptive text for each operating definition using the INQUIRY command. The parameters that can be changed by modifying the operating definition of a logical unit include the vendor identification, the device type, the device model, the SCSI compliance level, the SCSI specification level, the command set, and other parameters. The low-level hardware parameters including signal timing and parity definitions cannot be changed by modifying the oper- ating definition. The present operating definition of a logical unit with respect to an initiating controller can be determined at any time by exe- cution of an INQUIRY command. In some cases, it may be necessary to perform other commands including MODE SENSE and READ CAPACITY. Each logical unit begins at a particular operating definition. If the logical unit supports the CHANGE DEFINITION command, the present operating definition can be changed to any other operating definition supported by the Section 4. SPP Logical Operations 4-19 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 ----------------------------------------------------------------------------- CONCURRENT I/O PROCESS EXECUTION WITHIN A LOGICAL UNIT I/O PROCESS GROUP TAG TYPE MAX NUMBER PERMITTED UNTAGGED TREATED AS 1 PER INITIATING CONTROLLER SIMPLE UP TO NUMBER OF DIFFERENT INITIATING CONTROLLERS TAGGED SIMPLE UP TO NUMBER OF PROCESSES TARGET CONTROLLER CAN QUEUE INDEPENDENT OF NUMBER OF INITIATING CONTROLLERS TAGGED ORDERED 1 (FIFO) TAGGED HEAD OF QUEUE 1 (LIFO) ----------------------------------------------------------------------------- Figure 4-4. Concurrent I/O Process Execution Rules logical unit. The actual details of the operating definition of a logical unit are vendor-specific. If the operating definition is changed to one that does not include the CHANGE DEFINITION command, the target controller shall continue to accept the CHANGE DEFINITION command. If an error occurs before execution of a CHANGE DEFINITION command is com- plete, the original operating definition remains in effect after the command terminates. The new operating definition becomes active only after suc- cessful execution of the CHANGE DEFINITION command. Since the new operating definition may preclude the execution of I/O proc- esses that are already in progress, the target controller shall allow com- pletion of any I/O processes that are in its queues before executing the CHANGE DEFINITION command. Operating definition changes that may cause conflicts during normal operation with other initiating controllers shall be indicated to those initiators by generating a unit attention condition for each other initiating controller. The additional sense code shall be set to CHANGED OPERATING DEFINITION. 4.8 I/O PROCESS TERMINATION ____________________________ 4.8.1 NORMAL I/O PROCESS TERMINATION 4-20 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 4.8.2 ABNORMAL I/O PROCESS TERMINATION ;p Protocol error by either the initiating controller or the target con- troller cause an I/O process to be terminated. Specific instances are iden- tified thoroughout this standard. 4.8.2.1 Initiating Controller Caused Termination The TERMINATE I/O PROCESS, ABORT I/O PROCESS, ABORT, CLEAR QUEUE, and BUS DEVICE RESET messages provide a means to clear one or more I/O processes before normal termination. The order listed identifies the breadth of effect on the target controller with TERMINATE I/O PROCESS having the least effect, and BUS DEVICE RESET having the greatest effect. Each message is described briefly below. Each message is described, in detail, in the message description seciton. o The TERMINATE I/O PROCESS message causes an early termination to the identified I/O process under target control. Status and messages are returned. No other I/O processes are affected. o The ABORT I/O PROCESS message clears the identified I/O process. No status or messages are returned. No other I/O processes are affected. o The ABORT message clears all I/O processes for the selecting initiating controller on the specified logical unit or target controller routine of the target controller. The ABORT message clears the identified I/O process an all other I/O processes (active or queued) for the initiating controller. No status or messages are returned. o The CLEAR QUEUE message clears all I/O processes for all initiating con- trollers on the specified logical unit or target controller routine of the target controller. No status or messages are returned. o The BUS DEVICE RESET message clears all I/O processes for all initiating controllers on all logical units and all target controller routines of the target controller. No status or messages are returned. The SPP device then performs the equivalent of power-on initialization. 4.8.2.2 Target Controller Caused Termination 4.9 LOGICAL UNIT RESERVATION TERMINATION (MANDATORY) _____________________________________________________ (add condiserations of when reservations are removed. GRS) 4.10 PATH GROUP OPERATIONS (OPTIONAL) ______________________________________ (add considerations of path group mamagement. GRS) Section 4. SPP Logical Operations 4-21 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 4.10.1 SINGLE PATH MODE 4.10.2 MULTIPLE PATH MODE 4.10.3 SINGLE PATH STATUS 4.10.4 MULTIPLE PATH STATUS 4.11 ASSIGNMENT TERMINATION (OPTIONAL) _______________________________________ (add condiserations of when assignmane is removed. GRS) 4.12 PATH GROUP TERMINATION (OPTIONAL) _______________________________________ (add considerations of when path groups are removed. GRS) 4-22 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 5. SPP I/O PROCESS STRUCTURE _____________________________________ This section is divided into 5 parts: 1) Commands; 2) Status; 3) Contingent Allegiance; 4) Extended Contingent Allegiance; 5) Asynchronous Event Notification. 5.1 COMMANDS _____________ By specifying only the functions essential to communicate via this protocol, a wide range of peripheral devices of varying capability can operate in the same environment. Because subsets of the full command set may be imple- mented, optional functions are identified. A command consists of a command descriptor block and, in some instances, command parameter data. Singular commands are commands, possibly including command parameter data, which must appear in an I/O process by themselves. That is, there shall be no preceeding command with the link bit set to one and a singular command shall have its link bit set to zero. Supervisor commands are commands which shall not be executed in an I/O process unless specifically enabled by the initiating controller. Such com- mands normally affect access to logical units or extents. A supervisory function in the initiating controller indicates when supervisor commands are permitted in each I/O process. Such a supervisory function is optional, but it provides each initiating controller an opportunity to check the content of I/O processes which can affect availability and data reliability. The super- visory function can be in the Common Access Method implementation. Three terms commonly used with commands are receipt, acceptance, and exe- cution. Receipt of a command is not the same as acceptance of a command. Receipt refers only to the transfer of a command in an information packet. The command may, as part of its I/O process, go to the queued I/O process queue or to the active I/O process queue. Acceptance of a command means that the I/O process is active, the command is next to be executed, all fields are valid for the implementation, and the current conditions in the logical unit or target routine to permit attempting execution. A received command may be accepted or rejected. Section 5. SPP I/O Process Structure 5-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 Execution applies only to commands which have been received and accepted. The implemented procedure for the command is performed to the best ability of the target controller. The command may terminate successfully or with error. A command which is received, accepted, executed, and completed sucessfully causes status and a command completion message to be prepared for trans- mission to the initiating controller in an information packet. The status and command completion message may not be sent until later along with other status, data, and messages for the I/O process. A command which is received, accepted, and, after execution begins, termi- nates with an error detected by the target controller causes status to be prepared, a contingent or extended contingent allegiance to be established, sense data to be prepared. The information packet is sent at this time to inform the initiating controller of the error. Sense data may be included in the information packet in an autosense ILE. The final sequence of interface logical elements is: a status ILE indicating CHECK CONDITION or I/O PROCESS TERMINATED, an autosense ILE (optional), a message ILE indicating INITIATE RECOVERY (optional), and a message ILE indicating I/O PROCESS COMPLETE. See discussions of status, contingent allegiance and extended contingent alle- giance. A command which is received and rejected causes status to be prepared, a con- tingent allegiance to be established, sense data to be prepared, and status to be prepared for the I/O process. The information packet is sent at this time to inform the initiating controller of the error. 5.1.1 COMMAND SET IMPLEMENTATION REQUIREMENTS (MANDATORY) A device class is a group of devices that implement the mandatory common com- mands and functions in SPP and the mandatory commands and functions defined for one of the sections of SDCS. A device type is a specific implementation within a device class. Each device type may implement different optional features of its device class, but it shall implement the mandatory common commands and functions in SPP and the mandatory commands and functions in the appropriate section of SDCS for its device class. 5.1.2 RESERVED (MANDATORY) Reserved bits, fields, bytes, and code values are set aside for future stand- ardization. Their use and interpretation may be specified by future exten- sions to this standard. A reserved bit, field, or byte shall be set to zero. A target controller that detects a reserved bit, field, or byte that is not zero or detects a reserved code value shall shall reject the command and ter- minate the I/O process prior to attempting execution of the command. A con- tingent allegiance is established with the initiating controller. The sense key shall be set to ILLEGAL REQUEST. 5-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 5.1.3 COMMAND DESCRIPTOR BLOCK A command is communicated by sending a command descriptor block (CDB) to a target controller in an information packet. For several commands, the command descriptor block requires command parameter data (CPD). See the spe- cific commands for detailed information for which commands require command parameter data. The command descriptor block shall have the operation code as its first byte and a control field as its last byte. Command parameter data may be sent as an interface logical element in the same information packet as the CDB, in a separate information packet, or split into bursts across several information packets. If there is an invalid parameter in the command descriptor block or the command parameter data, the target controller shall reject the command and terminate the I/O process prior to attempting execution of the command. A contingent allegiance is established with the initiating controller. The sense key shall be set to ILLEGAL REQUEST. Table 5-1, Table 5-2 on page 5-4, and Table 5-3 on page 5-4 are typical command layouts. These are examples and do not specify the exact field layout for all commands. See the field layout for each command. General descriptions of the command descriptor block fields are given after the layouts. +---------------------------------------------------------------------------+ | Table 5-1. Typical Command Descriptor Block for Six-Byte Commands | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 | Operation Code (xxh) | +------+-------------------------+------------------------------------------+ | 1 | Reserved | (MSB) Logical Block Address (Cont'd) | +------+-------------------------+------------------------------------------+ | 2 - 3| Logical Block Address (if required) | | | (LSB) | +------+--------------------------------------------------------------------+ | 4 | (MSB) | | | Transfer Length (if required) | | | Command Parameter Data Length (if required) | | | Command Response Data Length (if Required) | | | (LSB) | +------+--------------------------------------------------------------------+ | 5 | Control Field | +------+--------------------------------------------------------------------+ Section 5. SPP I/O Process Structure 5-3 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 5-2. Typical Command Descriptor Block for Ten-Byte Commands | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 | Operation Code (xxh) | +------+--------------------------------------------------------------------+ | 1 | Reserved | +------+--------------------------------------------------------------------+ | 2 - 5| (MSB) | | | Logical Block Address (if required) | | | (LSB) | +------+--------------------------------------------------------------------+ | 6 | Reserved | +------+--------------------------------------------------------------------+ | 7 - 8| (MSB) | | | Transfer Length (if required) | | | Command Parameter Data Length (if required) | | | Command Response Data Length (if Required) | | | (LSB) | +------+--------------------------------------------------------------------+ | 9 | Control Field | +------+--------------------------------------------------------------------+ +---------------------------------------------------------------------------+ | Table 5-3. Typical Command Descriptor Block for Twelve-Byte Commands | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 | Operation Code (xxh) | +------+--------------------------------------------------------------------+ | 1 | Reserved | +------+--------------------------------------------------------------------+ | 2 - 5| (MSB) | | | Logical Block Address (if required) | | | (LSB) | +------+--------------------------------------------------------------------+ | 6 - 9| (MSB) | | | Transfer Length (if required) | | | Command Parameter Data Length (if required) | | | Command Response Data Length (if Required) | | | (LSB) | +------+--------------------------------------------------------------------+ | 10 | Reserved | +------+--------------------------------------------------------------------+ | 11 | Control Field | +------+--------------------------------------------------------------------+ 5-4 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 5.1.4 OPERATION CODE (MANDATORY) The first byte of all commands shall contain an operation code as defined in this standard. The operation code definition may change between device classes. Only the common commands are guaranteed to have the same meaning in all device classes. Operation codes are divided in four categories as defined in Figure 5-1 on page 5-6. The operation code (Table 5-4) of the command descriptor block has a group code field and a command code field. The three-bit group code field provides for eight groups of command codes. The five-bit command code field provides for thirty-two command codes in each group. Thus, a total of 256 possible operation codes exist. Operation codes are defined in SPP and SDCS. Opera- tion codes may be redefined in each device class section of SDCS. Only the commands in SPP are guaranteed to have the same meaning in all device classes. +---------------------------------------------------------------------------+ | Table 5-4. Operation Code | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 | Group Code | Command Code | +------+-------------------------+------------------------------------------+ | | | | | Group Codes: | | | | o Group 0 - six-byte commands (see Table 5-1 on page 5-3) | | o Group 1 - ten-byte commands (see Table 5-2 on page 5-4) | | o Group 2 - ten-byte commands (see Table 5-2 on page 5-4) | | o Group 3 - reserved | | o Group 4 - reserved | | o Group 5 - twelve-byte commands (see Table 5-3 on page 5-4) | | o Group 6 - vendor specific | | o Group 7 - vendor specific | +---------------------------------------------------------------------------+ 5.1.5 LOGICAL BLOCK ADDRESS The logical block address for logical units or within a partition of a logical unit shall begin with block zero and be contiguous up to the last logical block for that logical unit or within that partition. Not all device classes support logical block addressing. See the model at the beginning of each device class section in SDCS. For those commands providing logical block addresses: a six-byte command descriptor block contains a 21-bit logical block address; a ten-byte or twelve-byte command descriptor block contains a 32-bit logical block address. Logical block addresses in command parameter data have their length specified for each occurrence. See the specific command descriptions. Section 5. SPP I/O Process Structure 5-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 ----------------------------------------------------------------------------- OPERATION CODE TYPE DESCRIPTION --------- ------------------------------------------------------------------- M MANDATORY - COMMANDS SO DESIGNATED SHALL BE IMPLEMENTED IN ORDER TO MEET THE MINIMUM REQUIREMENT OF THIS STANDARD. O OPTIONAL - COMMANDS SO DESIGNATED, IF IMPLEMENTED, SHALL BE IMPLEMENTED AS DEFINED IN THIS STANDARD. V VENDOR SPECIFIC - OPERATION CODES SO DESIGNATED ARE AVAILABLE FOR VENDOR DEFINED COMMANDS. SEE THE VENDOR SPECIFICATIONS WHERE COMPATIBILITY IS DESIRED. R RESERVED - OPERATION CODES SO DESIGNATED SHALL NOT BE USED. THEY ARE RESERVED FOR FUTURE EXTENSIONS TO THIS STANDARD. ----------------------------------------------------------------------------- Figure 5-1. Operation Code Types (drop duplicate 6 or 10 byte commands in favor of 10 or 12 byte commands? also increase others now? GRS) 5.1.6 TRANSFER LENGTH The transfer length field specifies the amount of data to be transferred, usually the number of blocks. Not all commands provide a transfer length field. A target controller shall not attempt to transfer or process more data than specified by the command descriptor block transfer length value (i.e., block count times block size for fixed block formats). An initiating controller shall not attempt to transfer more data specified by the command descriptor block transfer length value (i.e., block count times block size for fixed block formats). For several commands the transfer length indicates the requested number of bytes to be sent as defined in the command description. For these commands the transfer length field may be identified by a different name. See the individual command descriptions for further information. Several commands that use one byte for the transfer length allow up to 256 blocks or bytes of data to be transferred by one command. A transfer length value of 1 to 255 indicates the maximum number of blocks or bytes that shall be transferred. A value of zero indicates 256 blocks or bytes. At least one block or byte is specified for transfer in any such command. Some commands specify that a value of zero means that no bytes or blocks are to be trans- ferred. This shall not be considered as an error. In commands that use more than 8 bits for the transfer length, a transfer length of zero indicates that no data transfer shall take place. A value of 5-6 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 one or greater indicates the maximum number of blocks or bytes that shall be transferred. A target controller which detects the length of the logical block data from the initiating controller to be different than specified in the command descriptor block shall reject the command, terminate the I/O process with contingent allegiance, and set the sense key to .... (? GRS) Refer to the specific command descriptions for further information. 5.1.7 COMMAND PARAMETER DATA LENGTH The command parameter data length field is used to specify the exact number of bytes in command parameter data. An initiating controller shall not include, as part of the command, command parameter data which exceeds the length specified in the command descriptor block. Command parameter data may be included as a subsequent interface logical element in the same information packet as the command descriptor block, a separate information packet, or split into bursts across multiple information packets. This field is typi- cally used in command descriptor blocks for command parameter data that are sent to a target controller (e.g., mode parameters, diagnostic parameters, log parameters, etc.) but which is not logical block data. A command parameter data length field of zero indicates that no data shall be transferred. This condition shall not be considered as an error. A target controller which detects the length of the command parameter data to be different than specified in the command descriptor block shall reject the command, terminate the I/O process with contingent allegiance, and set the sense key to ILLEGAL REQUEST. (SPP+SDCS commands may require changes. GRS) 5.1.8 COMMAND RESPONSE DATA LENGTH The command response data length field specifies the maximum number of bytes that a target controller may transfer as command response data. The command response data length is used to limit the amount of command response data (e.g., sense data, mode data, log data, diagnostic data, etc.) returned to an initiating controller by a target controller. A command response data length of zero indicates that no data shall be transferred. This condition shall not be considered as an error. The target controller may place command response data in a single command response data information logical element, or split the command response data over multiple information packets. The total length of the data bytes shall not exceed the command response data length specified in the command descriptor block. Since target controllers prepare information packets, if a target controller attempts to include command response data than is greater than the length in the CDB value, ....(? GRS) Section 5. SPP I/O Process Structure 5-7 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 (SPP and SDCS CDBs may require changes. GRS) 5.1.9 CONTROL FIELD (MANDATORY) The control field is the last byte of every command descriptor block. The control field is defined in Table 5-5. +---------------------------------------------------------------------------+ | Table 5-5. Control Field | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | - | Vendor Specific| Reserved | Flag | Link | +------+----------------+----------------------------------+--------+-------+ Support for the link bit and flag bit is mandatory for target controllers. Singular commands require that each such commands be in an I/O process by themselves. The link bit shall be zero. (See the common commands.) All device class commands support both the link bit and the flag bit. 5.1.9.1 Link Bit (Mandatory) The link bit is used to continue an I/O process across multiple commands. Status values referred to are described in later in this section. The last or only command of a set of linked commands has its link bit set to zero. All commands of an I/O process, except the last or only command shall have the link bit set to one. A link bit of one indicates that the initiating controller requests a contin- uation of the I/O process using the target controller active I/O process queue for the next command or wait for a new command from the initiating con- troller upon successful transfer of status and messages for the current command. If the link bit is one, and if the command completes successfully, the target controller shall return INTERMEDIATE or INTERMEDIATE-CONDITION MET status and shall then send one of the two messages defined by the value of the flag bit. If an active I/O process is partially in the target controller with the remaining portion in the initiating controller, the target controller shall send required information to the initiating controller in one or more infor- mation packets sufficient to establish the completion of all commands, in sequence, up through the present command. The initiating controller shall then transfer one or more information packets to continue the I/O process. These information packets shall not be placed in the queued I/O process queue. 5-8 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 If the link bit is zero, and if the command completes successfully, the target controller shall send GOOD or CONDITION MET status and the I/O PROCESS COMPLETE message. The I/O process terminates. If the link bit is zero or one, and if the command completes unsuccessfully, the target controller shall send appropriate status and the I/O PROCESS COM- PLETE message. That is, if the command is received, accepted and execution ends with an error (as opposed to an initiating controller forced termi- nation), the I/O process terminates at the completion of contingent alle- giance or extended contingent allegiance. If the link bit is set to one in a singular command, the target controller shall reject the command and terminate the I/O process with contingent alle- giance. The sense key shall be set to ILLEGAL REQUEST. 5.1.9.2 Flag Bit (Mandatory) The flag bit specifies which message the target controller shall return to the initiating controller if the link bit is one and the command completes without error. Status values referred to are described in this section. The flag bit shall be set to zero if the link bit is zero. If link bit is zero and the flag bit is one, the target controller shall reject the command and terminate the I/O process with contingent allegiance. The sense key shall be set to ILLEGAL REQUEST. If the flag bit is zero and the link bit is one, and if the command completes successfully, the target controller shall send the LINKED COMMAND COMPLETE message. If the flag bit is one and the link bit is one, and if the command completes successfully, the target controller shall send the LINKED COMMAND COMPLETE (WITH FLAG) message. 5.2 STATUS (MANDATORY) _______________________ The status byte and its status byte code are specified in Table 5-6 on page 5-10 and Figure "Status Byte Code", respectively. A status byte shall be sent from the target controller to the initiating controller at the com- pletion of each command unless the command is terminated by one of the fol- lowing events: o an ABORT I/O PROCESS message, o an ABORT message, o a CLEAR QUEUE message, o a BUS DEVICE RESET message, o an unexpected disconnect condition, or o a hard reset condition. In some cases, status transfer may occur prior to transferring a command descriptor block. Section 5. SPP I/O Process Structure 5-9 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 Status transfer can lead to a contingent allegiance condition, an extended contingent allegiance condition, or be only a report. Each status byte code identifies the effect in the target controller. +---------------------------------------------------------------------------+ | Table 5-6. Status Byte | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 | Reserv|d Status Byte Code | Reserv|d +------+-------+----------------------------------------------------+-------+ A status byte code value which leads to contingent allegiance or extended contingent allegiance shall cause the target controller to prepare sense data for the initiating controller to help identify the error or problem. Sense data is a special form of command response data which may be transferred to the initiating controller in response to a REQUEST SENSE command, during asynchronous event notification, or as autosense ILE appended behind the status ILE for these selected status byte code values. See the REQUEST SENSE command and the SEND command in the Processor Device Class of SDCS for the format of sense data. 5-10 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 5-7. Status Byte Code | +----------------------------+----------------------------+----------+------+ | Bits of Status Byte | | | | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |7 | 6 | 5 |4 | 3 | 2 |1 | 0 | Status | Type | Suppo|t +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |0 | 0 | 0 |0 | R | GOOD | Report | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |0 | 0 | 0 |1 | R | CHECK CONDITION | CA, ECA | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |0 | 0 | 1 |0 | R | CONDITION MET | Report | O | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |0 | 1 | 0 |0 | R | BUSY | Report | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |1 | 0 | 0 |0 | R | INTERMEDIATE | Report | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |1 | 0 | 1 |0 | R | INTERMEDIATE - CONDITION ME| Report | O | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 0 |1 | 1 | 0 |0 | R | RESERVATION CONFLICT | Report | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 1 |0 | 0 | 0 |1 | R | I/O PROCESS TERMINATED | CA, ECA | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 0 | 1 |0 | 1 | 0 |0 | R | QUEUE FULL | Report | M | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ |R | 1 | 0 |1 | 1 | 0 |0 | R | ASSIGNMENT CONFLICT | Report | O | +--+---+---+--+---+---+--+---+----------------------------+----------+------+ | All Other Codes | Reserved | | | +----------------------------+----------------------------+----------+------+ | Key: R - Reserved bit = 0b | | CA - Contingent Allegiance | | ECA - Extended Contingent Allegiance | | M - Mandatory | | O - Optional | +---------------------------------------------------------------------------+ 5.2.1 STATUS CODES (MANDATORY) The definitions of the status byte codes are given below, and the code values are shown in Table 5-7. GOOD. This status or CONDITION MET indicates that the target controller has successfully completed a single command I/O process or the last command of a set of linked commands for an I/O process. See INTERMEDIATE status for all commands in a set of linked commands with the link bit set to one. This is a report status from a target controller. CHECK CONDITION. This status indicates that an error has occurred. This status code requires contingent allegiance or extended contingent allegiance be established in the target controller. CONDITION MET. This status or INTERMEDIATE-CONDITION MET is returned when- ever the requested operation is satisfied for certain commands. (See the Section 5. SPP I/O Process Structure 5-11 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SEARCH DATA and PREFETCH commands). The link bit for commands receiving CON- DITION MET status shall be zero. This is a report status from a target con- troller. BUSY. This status shall be returned whenever a target controller is unable to retain an information packet from an otherwise acceptable initiator (i.e., no reservation conflicts). The recommended initiator recovery action is to issue the command again at a later time. See RESERVATION CONFLICT for infor- mation packets transferred by unacceptable initiators. The information packet is not retained by the target controller. This is a report status from a target controller. For initiating controllers, refer to the RESEND PREVIOUS INFORMATION PACKET message. INTERMEDIATE. This status or INTERMEDIATE-CONDITION MET shall be returned for every successfully completed command in a set of linked commands where the link bit is set to one. If INTERMEDIATE or INTERMEDIATE-CONDITION MET status is not returned for each command with its link bit set to one, the I/O process is terminated. This is a report status from a target controller. INTERMEDIATE-CONDITION MET. This status is a combination of CONDITION MET and INTERMEDIATE status. (See the SEARCH DATA and PREFETCH commands). The link bit for commands receiving INTERMEDIATE-CONDITION MET status shall be one. This is a report status from a target controller. RESERVATION CONFLICT. This status shall be returned whenever an initiator attempts to access a logical unit or an extent within a establish an I/O process for a logical unit or an extent within a logical unit that is reserved with a conflicting reservation type. The recommended initiator recovery action is to transfer the information packet again at a later time. An I/O process shall not be established in the target controller. This is a report status from a target controller. I/O PROCESS TERMINATED. This status shall be returned whenever the target terminates an active I/O process after processing a TERMINATE I/O PROCESS message. This status code requires contingent allegiance or extended contin- gent allegiance be established in the target controller. QUEUE FULL. This status is returned when a simple queue, ordered queue, or head of queue I/O process is attempted to be established and the queued I/O process queue is full. This status is also returned for information packets of an established queued I/O process when there is insuficcient space to store more information packets for the I/O process. The information packet is not placed in the queued I/O process queue. This is a report status from a target controller. For initiating controllers, refer to the RESEND PRE- VIOUS INFORMATION PACKET message. ASSIGNMENT CONFLICT. This status shall be returned whenever an initiator attempts to access a logical unit that is assigned to another path. An I/O process shall not be established in the target controller. This is a report status from a target controller. 5-12 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 5.2.2 STATUS CODE REPORTING PRIORITY (MANDATORY) The priority of reporting status byte codes proceeds from the most restric- tive to the least restrictive meanings. +---------------------------------------------------------------------------+ | Table 5-8. Status Byte Code Reporting Priority | +---------------------------------------------------------------+-----------+ | STATUS NAME | PRIORITY | +---------------------------------------------------------------+-----------+ | ASSIGNMENT CONFLICT. | Highest | +---------------------------------------------------------------+-----------+ | RESERVATION CONFLICT. | | +---------------------------------------------------------------+-----------+ | BUSY. | | +---------------------------------------------------------------+-----------+ | QUEUE FULL. | | +---------------------------------------------------------------+-----------+ | I/O PROCESS TERMINATED. | | +---------------------------------------------------------------+-----------+ | CHECK CONDITION. | | +---------------------------------------------------------------+-----------+ | INTERMEDIATE or INTERMEDIATE - CONDITION MET. | | +---------------------------------------------------------------+-----------+ | GOOD or CONDITION MET. | Lowest | +---------------------------------------------------------------+-----------+ ASSIGNMENT CONFLICT is the highest priority code since it indicates a condi- tion in the target controller which prevents I/O processes from being estab- lished until the assignment is removed by some third party. RESERVATION CONFLICT is the second highest priority code since it indicates a condition in the target controller which prevents I/O processes from being established until the reservation is removed by some third party. BUSY and QUEUE FULL indicate that no reservation conflict exists, but that at the present time, the target controller cannot accept additional information packets. BUSY indicates a target controller condition which has resources tied up which prevent checking the queue status. QUEUE FULL merely indicates a lack of available resources to store information packets. I/O PROCESS TERMINATED and CHECK CONDITION indicate an error in processing some portion of an I/O process. I/O PROCESS TERMINATED indicates forced ter- mination of an I/O process by the initiating controller. CHECK CONDITION indicates a target controller detected error which prevents further proc- essing of the I/O process. INTERMEDIATE and INTERMEDIATE-CONDITION MET status byte codes are of equal priority since the use of the status is dictated by the command processing rules. Intermediate status indicates a continuing responsibility on the part of the target controller and initiating controller to continue an I/O process containing a set of linked commands. Section 5. SPP I/O Process Structure 5-13 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 GOOD and CONDITION MET status byte codes are of equal priority since the use of the status is dictated by the command processing rules. Either status indicates that the I/O process is terminated normally by the target con- troller. 5.3 CONTINGENT ALLEGIANCE CONDITION (MANDATORY) ________________________________________________ Implementation of contingent allegiance (CA) is a mandatory. See the glos- sary for a definition. The continginent allegiance condition permits reporting an error to an initiating controller which requires transferring an appropriate status and corresponding sense data. The sense data may be held in the target controller until requested by or deleted by the initiating con- troller, or it may be included as an autosense ILE following the status ILE at the time the error is reported. A contingent allegiance and its subse- quent clearing results in termination of the affected I/O process. Any information packets held in the target controller for the I/O process are deleted when status is reported. If contingent allegiance is the reporting method selected for an error, the condition shall exist from detection of an error which causes CHECK CONDITION or I/O PROCESS TERMINATED status or following an unexpected disconnect. The alternative condition is extended contingent allegiance. Target controllers shall report a maximum of one contingent allegiance per initiating controller per logical unit or target routine. If autosense is used for reporting contingent allegiance, the condition is cleared with suc- cessful transmission of the information packet. If CA or ECA is outstanding to the initiating controller for the logical unit, a new CA condition is not reported until the prior existing condition is cleared. This is required because the recovery action consists of one or more untagged I/O processes. If multiple CAs or ECAs are reported, the target controller and initiating controller cannot determine which condition to respond to or which condition is being reported. While the contingent allegiance condition exists the target shall preserve the appropriate sense data not successfully transmitted as autosense. The condition persists until sense data has been retrieved or the initiating con- troller has taken an action to reset the held sense data. If the target con- troller selects to report the sense data using autosense (i.e., including the sense data as a CRD ILE with the status) the contingent allegiance condition is cleared with successsful transfer of the information packet since all reporting requirements have been met. While the contingent allegiance condition exists, if the target is unable to maintain separate sense data, the target shall respond to any other requests for access to the logical unit or target routine from another initiator with a BUSY status. Execution of commands for the logical unit or target routine for which the contingent allegiance condition exists shall be suspended until the contingent allegiance condition is cleared. If only status is reported to the initiating controller, the contingent alle- giance condition shall be preserved for the H_C_x_y nexus on path where it is reported, until it is cleared. The type of nexus and conditions in effect 5-14 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 for the nexus, established with the connect, determine which path is used to report the status leading to contingent allegiance. The contingent allegiance condition shall be cleared upon the generation of a hard reset condition, or by an ABORT message, a BUS DEVICE RESET message, or any subsequent command for the nexus. If the subsequent command is a REQUEST SENSE command, the sense data is reported in response to the command and then the contingent allegiance condition is cleared. 5.4 EXTENDED CONTINGENT ALLEGIANCE CONDITION (OPTIONAL) ________________________________________________________ Implementation of extended contingent allegiance (ECA) is optional. See the glossary for a definition. The extended contingent allegiance condition extends a contingent allegiance condition for an H_C_x_y nexus to include a protected period of time for the initiating controller to take appropriate action related to the error reported. An extended contingent allegiance and its subsequent clearing results in termination of the affected I/O process. Any information packets held in the target controller for the I/O process are deleted when status is reported. An extended contingent allegiance condition should not be generated for every CHECK CONDITION or I/O PROCESS TERMINATED status that occurs. Simple errors not requiring an extended recovery may be dealt with by using the contingent allegiance protocol. Target controllers shall report a maximum of one ECA per initiator per logical unit or target routine. If CA or ECA is outstanding to the initi- ating controller for the logical unit, a new ECA condition is not reported until the prior existing condition is cleared. This is required because the recovery action consists of one or more untagged I/O processes. If multiple CAs or ECAs are reported, the target controller and initiating controller cannot determine which condition to respond to or which condition is being reported. This condition is generated by the target sending an INITIATE RECOVERY message on the same path as and following the CHECK CONDITION or I/O PROCESS TERMINATED status and prior to the I/O PROCESS COMPLETE message. The sense data may be held in the target controller waiting for a REQUEST SENSE command to retrieve it, or the sense data may be included with the status report as a CRD ILE immediately following the status ILE and before the INITIATE RECOVERY message. Retriveing sense data does not end an extended contingent alle- giance as it does a contingent allegiance. With either method of reporting sense data, this condition shall be preserved until it is cleared by a BUS DEVICE RESET message, a RELEASE RECOVERY message, or a hard reset condition. If the target controller needs to generate an extended contingent alle giance condition during an asynchronous event notification, it shall send an INITIATE RECOVERY message prior to the SEND command. While the extended contingent allegiance condition exists, the target shall respond to any other request for access to the logical unit from any other path with BUSY status. Execution of commands for the logical unit for which the extended contingent allegiance condition exists from the active I/O Section 5. SPP I/O Process Structure 5-15 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 process queue shall be suspended until the extended contingent allegiance condition is cleared. No queued I/O process shall be made active. An extended contingent allegiance condition can be generated for only one nexus at a time. The extended contingent allegiance condition is cleared as defined above when a RELEASE RECOVERY message is received from the initiating controller for which the INITIATE RECOVERY message was sent. During an extended contingent allegiance, only untagged I/O processes from the eligible path shall be executed for the logical unit. If the initiator sends a tagged I/O process, the target controller shall respond with QUEUE FULL status. After the extended contingent allegiance condition is cleared any commands remaining in the command queue shall be processed per the rule in control mode pate parameters. (cross check with queued I/O processes. GRS) During the extended contingent allegiance condition, appropriate error recovery sequences may be executed. Such I/O processes can correct data, modify or delete queued commands, perform LOG SENSE commands and obtain diag- nostic information. Extended contingent allegiance is recommended for error conditions that may require execution of multiple-step error-recovery proce- dure without interference from other initiators. The recommended recovery procedure is target controller vendor specific. The initiating controller is not required to follow the recommended recovery procedure; it must only exit by sending a RELEASE RECOVERY message. However, the target controller func- tion may be compromised as a result of not following the recommended proce- dure. 5.5 ASYNCHRONOUS EVENT NOTIFICATION (MANDATORY) ________________________________________________ Implementation of asynchronous event notification is mandatory. An asynchro- nous event is one which occurs in a target controller which affects the oper- ation of the target controller with its initiating controller(s), but which does not occur as a result of an active I/O process. The unit attention con- dition is an instance where asynchronous event notification shall be used. An example of an asynchronous event is medium removal in a sequential access device, a removable optical device, or a CD_ROM. A device, which normally functions as a target controller, shall implement initiator mode to notify an initiating controller of an asynchronous event. Retrieval of the INQUIRY data by target controllers shall be performed prior to the first use of asynchronous event notification with an initiating con- troller through an initiator. Devices that respond to an INQUIRY command as a processor device class, may be notified of asynchronous events using this protocol. Such devices are normally initiators attached to an initiating controller. Asynchronous event notification may not be used with a device that reports a device class other than procressor (e.g., devices executing COPY commands). The INQUIRY command should be issued to logical unit zero of each device responding to selection. Each device that responds as processor device class shall be issued a TEST UNIT READY command to determine that the device is ready to receive an asyn- chronous event notification. A device returning CHECK CONDITION status 5-16 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 without autosense is issued a REQUEST SENSE command to clear any pending unit attention condition. Devices of the processor device class which return GOOD status when issued a TEST UNIT READY command shall accept a SEND command with an AEN bit of one. A SEND command with an AEN bit of one is interpreted as an asynchronous event by an initiating controller. The sense data identifying the condition being reported shall be returned as a command parameter data of the the SEND command (See Processor Device Class of SDCS). An error condition or unit attention condition shall be reported once per occurrence of the event causing it (See contingent allegiance, and extended contingent allegiance). Notification of command-related error conditions shall be sent only to the initiating controller where the connect was made for the I/O process. That is, any path to the initiating controller may be used for asynchronous event notification. This protocol is not intended to be used while an H_C_L nexus, H_C_R nexus, or H_C_L_Q nexus exists with an initiating controller for an active I/O process. Asynchronous event notification is not intended for use with target routines (i.e., an H_C_R nexus) but its use is not prohibited. The procedure to identify candidate initiating controllers through their ini- tiators shall be repeated whenever a target controller deems it appropriate or when an event occurs that may invalidate the current information. (See SYNCHRONOUS DATA TRANSFER REQUEST message, for examples of these events.) The four principal uses of asynchronous event notification are: (1) informing a processor device of an error condition encountered after I/O process completion; (2) informing all processor devices that a newly initialized device is avail- able; (3) informing all processor devices of other unit attention conditions; and, (4) informing all processor devices of other asynchronous events. Other uses of asynchronous event notification are not prohibited. An example of the first case above is a device that implements a write cache. If the target is unable to write cached data to the medium, it may use an asynchronous event notification to inform the initiating controller of the failure. An extended contingent allegiance condition may also be established during the same H_C_L nexus used for the asynchronous event notification. An example of the second case above is using the asynchronous event notifica- tion protocol to notify initiating controllers that a system resource has become available. The sense key in the sense data sent to the initiating controller shall be set to UNIT ATTENTION. An example of the third case above is a device that supports removable media. Asynchronous event notification may be used to inform an initiating con- Section 5. SPP I/O Process Structure 5-17 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 troller of a not-ready-to-ready transition (medium changed) or of an operator initiated event (e.g., activating a write protect switch or activating a start or stop switch). An example of the fourth case above is a sequential-access device performing a REWIND command where the immediate bit had been set to one. Asynchronous event notification may be used to inform an initiator that the beginning of medium has been reached or that the rewind operation failed. Completion of a CD-ROM AUDIO PLAY command started in the immediate mode is another example of this case. 5-18 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 6. SPP INFORMATION PACKET STRUCTURE ____________________________________________ This section contains the information packet description for SPP. 6.1 INFORMATION PACKET STRUCTURE _________________________________ An information packet is set of self-describing interface logical elements in defined orders surrounded by the appropriate interface control fields neces- sary to send the logical content of the packet on a physical bus (Table 6-1). Information packets shall be a multiple of 4 bytes in length. Pad bytes are added to permit construction of information packets of such lengths. The value of the pad bytes is not specified in Fiber Channel. The value of pad bytes in SPP shall be 00h. An information packet shall contain at least one interface logical element and shall not contain more than 255 interface logical elements. If an information packet is not a multiple of 4 bytes long or there are zero or greater than 255 interface logical elements in the information packet, the information packet shall be rejected. The target controller returns an information packet with an INVALID INFORMATION PACKET message. +---------------------------------------------------------------------------+ | Table 6-1. Information Packet Structure | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 | | | to | Interface Control Prefix Fields | | m | | +------+--------------------------------------------------------------------+ | m+1 | | | to | One to 255 Interface Logical Elements | | n | | +------+--------------------------------------------------------------------+ | n+0 | | | to | Interface Control Suffix Fields | | n+3 | | +------+--------------------------------------------------------------------+ Section 6. SPP Information Packet Structure 6-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 6.1.1 INTERFACE CONTROL FIELDS (MANDATORY) The interface control fields encapsulate the information content (ILEs) of the logical operations. The identify function for both initiating control- lers and target controllers uses the interface control fields to establish the nexus and direct each information packet in managing an I/O process. +---------------------------------------------------------------------------+ | Table 6-2. Interface Control Prefix Fields | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 - 1| (MSB) | | | Packet Length | | | (LSB) | +------+--------------------------------------------------------------------+ | 2 | Packet Type | +------+--------------------------------------------------------------------+ | 3 | Reserved | +------+-------+--------+--------+-------------------------+----------------+ | 4 | MltPat| SuspMpt| EnbSpvr| Reserved | Pad Byte Count | +------+-------+--------+--------+--------+-------+--------+----------------+ | 5 | LUNTRN| LUNTRN | QNexus | HOQ | OrdSim| Reserved | | | Valid | | | | | | +------+-------+--------+--------+--------+-------+-------------------------+ | 6 | Initiating Controller Port Number | +------+--------------------------------------------------------------------+ | 7 | Reserved | +------+--------------------------------------------------------------------+ | 8 | Original Initiator SPP Address | +------+--------------------------------------------------------------------+ | 9 | Reserved | +------+--------------------------------------------------------------------+ | 10 | Original Target SPP Address | +------+--------------------------------------------------------------------+ | 11 | Target Controller Port Number | +------+--------------------------------------------------------------------+ | 12 | LUNTRNID | +------+--------------------------------------------------------------------+ | 13 | Queue Tag | +------+--------------------------------------------------------------------+ | 14-15| Sending SPP Device Sequence Number | +------+--------------------------------------------------------------------+ Table 6-2 shows the interface control prefix fields. All reserved fields and bits shall be set to zero. The packet length field indicates the total length of the information packet in bytes, including the interface control prefix fields and the interface control suffix fields. The actual usable maximum packet length is result of negotiation and may be further restricted by maximum burst length negoti- ations. This value shall be a multiple of 4 and greater than or equal to 24. 6-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 The packet type field identifies the general content of an information packet. o A packet type code of 00h indicates an information packet to start a new nexus. o A packet type code of 01h indicates a target controller initiated packet to terminate an I/O process. o A packet type code of 02h indicates an intermediate information packet from an initiating controller to continue an I/O process established with an information packet of type 00h. o A packet type code of 03h indicates an intermediate information packet from a target controller to continue an I/O process established with an information packet of type 00h. o A packet type code of 04h indicates that a nexus is requested to be established by the initiating controller from a target controller because of asynchronous event notification. o Packet type code values of 05h through FFh are reserved. A multiple path (MltPath) bit of one specifies that the initiating controller considers the path capable of multiple path operation. When the value is zero, the initiating controller considers the path to be in single path mode. The setting has no effect on any other active or queued I/O process in the target controller. This value shall remain unchanged in all information packets for the nexus. The MltPath bit indicates the initiating controller state of the path. The target controller shall confirm that its state is the same. If the target controller state is different, it shall not process the information packet and shall indicate the error by sending an information packet with the INVALID INFORMATION PACKET message. Accepting this bit set to one is optional. A suspend multiple path (SuspMpth) bit of one specifies that the initiating controller requires the target controller to stop multiple path operation for an I/O process. The effect is to form an H_I_T_C nexus from the H_C nexus. The SuspMpth bit is interpreted for each nexus. The setting has no effect on any other active or queued I/O process in the target controller. If the MltPath bit is set to 0b, the SuspMpth bit is ignored and the target con- troller shall operate in single path mode for the I/O process. If the MltPath bit is set to 1b and the SuspMpth bit is set to 1b, the target con- troller shall operate in single path mode for the I/O process. If the MltPath bit is set to 1b and the SuspMpth bit is set to 0b, the target con- troller may operate in single path mode or multiple path mode for the I/O process. Accepting this bit set to one is optional. A enable supervisor command (EnbSpvr) bit of one specifies that the initi- ating controller has granted the target controller the privilege of executing any valid supervisor command received during the I/O process in which the enable supervisor command bit is set to 1b If the bit is set to zero and a supervisor command is present in the I/O process, the target controller shall Section 6. SPP Information Packet Structure 6-3 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 terminate the I/O process with contingent allegiance and prepare sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to SUPERVISOR COMMANDS NOT ENABLED. (SPP update required? GRS) The enable supervisor command bit setting is interpreted for each nexus. The setting has no effect on any other active or queued I/O process in the target controller. Accepting this bit set to one is optional. The pad byte count field indicates the number of pad bytes added at the end of the interface logical elements to construct an information packet which is a multiple of 4 bytes in length. A logical unit number/target routine number valid (LUNTRN Valid) bit of zero specifies that the I/O process is to the target controller and forms an H_C nexus. A LUNTRN Valid bit of one specifies that the information packet is for a logical unit or target routine as specified by the LUNTRN bit and forms an H_C_x_y nexus. Certain information packets cannot be directed to a spe- cific logical unit or target routine. The target controller shall use this bit, when 1b, as a valid field indicator for the LUNTRN, HOQ, OrdSim, LUNTRNID, and Queue Tag fields. This value shall remain unchanged in all information packets for the nexus. An I/O process with a LUNTAR Valid bit of zero shall operate in single path mode. A logical unit/target (LUNTRN) bit of zero specifies that the I/O process is for a logical unit; an H_C_L or H_C_L Q nexus will be formed depending on the value of the QNexus bit. A LUNTRN bit of one specifies that the I/O process is for a target routine; an H_C_R nexus is formed. The target controller shall ignore this bit when the LUNTRN Valid bit is zero. The logical unit or target routine is identified in the LUNTRNID field. When sent by a target controller during a reconnection, the value of this bit shall be the same as the most recent value received for this I/O process. The value supplied in this field with the connect shall not change during the information packet exchange related to the nexus from the value transferred in the information packet with packet code 00h. The LUNTRN bit is set as appropriate during a connect for asynchronous event notification. The queue nexus (QNexus) bit when one indicates that the nexus is of the form H_C_L_Q. When the queue nexus bit is zero, the nexus formed will be of the form H_C_L, or H_C_R. The target controller shall use this bit, when 1b, as a valid field indicator for the HOQ, OrdSim, and Queue Tag fields. This value shall remain unchanged in all information packets for the nexus. If tagged queuing is implemented, support of this bit set to one shall be imple- mented. A HOQ bit of one specifies that the I/O process is to be placed at the head of the queued I/O process queue for the initiating controller. This field is to be interpreted only when QNexus is 1b. This value shall remain unchanged in all information packets for the nexus. If the QNexus bit is supported, this bit shall be supported. A OrdSim bit of one specifies ordered queue processing in the target con- troller. A OrdSim bit of zero specifies that a simple tagged I/O process is requested in the target controller. This field is to be interpreted only when QNexus is 1b. This value shall remain unchanged in all information 6-4 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 packets for the nexus. If the QNexus bit is supported, this bit shall be supported. The next nine fields identify the path on which the connect was made for the nexus. The LUNTRN bit identifies whether the nexus is directed toward a logical unit or a target routine. These fields shall not change in any information packet of any type transferred for the nexus once established as specified below. These fields along with the LUNTRN Valid, LUNTRN QNexus, HOQ, and OrdSim bits identify the nexus to be reestablished in any later con- nection on any path for the nexus, and also in the target controller, when operating in a multiple path environment. The initiating controller port number identifies the internal port number assigned by the initiating controller to the port where the connect was made using an information packet packet type code of 00h. This value shall remain unchanged in all information packets for the nexus. The original initiator SPP address identifies the external name of the SPP device on the initiating controller where the connect was made using an information packet packet type code of 00h. This value shall remain unchanged in all information packets for the nexus. The original target SPP address identifies the SPP device, from the initi- ating controller's perspective on the selected SPP bus, information where the connect was made using an information packet packet type code of 00h. This value shall remain unchanged in all information packets for the nexus. The target port number identifies the physical port number assigned by the target controller to the target SPP address. This field shall be FFh when the packet type code is 00h for the first I/O process between two logical elements. The target controller supplies its unique port number value in the response information packet. Once the initiating controller receives an information packet for the nexus that contains the target port number, all later information packets sent with packet type code 00h on the same physical path shall have the target port number placed in this field. The target con- troller may receive multiple information packets during the connect with a target port number value of FFh. If the target controller receives an infor- mation packet with packet type code 00h, other than as specified above, and the target port number does not match the internally assigned port number, the target controller shall not process the information packet and shall indicate the error by sending an information packet with the INVALID INFORMA- TION PACKET message. The logical unit number target routine number (LUNTRNID) field specifies a logical unit number if the LUNTRN Valid bit is set to one and the LUNTRN bit is zero. The LUNTRNID field specifies a target routine number if the LUNTRN Valid bit is set to one and the LUNTRN bit is one. The response to an invalid value in the LUNTRNID field is described in a later section. The target controller shall ignore this field when the LUNTRN Valid bit is zero. This value shall remain unchanged in all information packets for the nexus. The queue tag field has meaning only when the QNexus bit is set to 1. If the QNexus bit is set to zero, this field shall be set to 00h. If the target controller detects any value, other than 00h, it shall indicate the error by Section 6. SPP Information Packet Structure 6-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 sending an information packet with an INVALID INFORMATION PACKET message. The target controller shall ignore this field when the LUNTRN Valid bit is zero. This value shall remain unchanged in all information packets for the nexus. The sending SPP device sequence number is a value from 0 to 65535 which spec- ifies the sequence of an information packet relative to other information packets for the same nexus. The initiating controller shall set this value to zero when the packet type code is 00h. It then increments the value by one for each subsequent packet it sends for the same nexus. If the value reaches 65535, the next sequence number is 0 (i.e., the sequence counter wraps). The target controller shall set the value of this field to zero on the first information packet sent in response to a nexus. It shall then increment the counter by one for each subsequent information packet. If the value reaches 65535, the next sequence number is 0 (i.e., the sequence counter wraps). The sending SPP device seqyence number shall be zero when the packet type code is 04h. +---------------------------------------------------------------------------+ | Table 6-3. Interface Control Suffix Fields | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | none | | | or | | | -n | Zero to 3 Pad Bytes | | to | | | -1 | | +------+--------------------------------------------------------------------+ Each information packet shall be rounded up to the nearest multiple of 4 bytes by adding from zero to three pad bytes. The value of -n in Table 6-3 may be -1, -2, or -3 if any pad bytes are required. Including more than 3 pad bytes shall indicate the error by sending an information packet with the INVALID INFORMATION PACKET message. The value of each pad byte shall be 00h. 6.1.2 INTERFACE LOGICAL ELEMENTS (MANDATORY) The interface logical elements are messages, command descriptor blocks, command parameter data, command response data, logical blocks, status, and autosense. A self-describing set of fields prefixes the interface logical elements to permit the information packet content to be correctly identified, checked, and processed at the receiving SPP port. A self-describing interface logical element is composed of four fields: the element length, the element type, a reserved field, and the logical element bytes. See Table 6-4 on page 6-7. 6-6 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 6-4. Interface Logical Element | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | BIT| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | BYTE | | | | | | | | | +------+-------+--------+--------+--------+-------+--------+--------+-------+ | 0 - 1| (MSB) | | | Element Length | | | (LSB) | +------+--------------------------------------------------------------------+ | 2 | Element Type | +------+--------------------------------------------------------------------+ | 3 | Reserved | +------+--------------------------------------------------------------------+ | 4 - n| Element Bytes | +------+--------------------------------------------------------------------+ The element length is a two-byte binary field. The value range is from 4 to 65535. If the element length value is 4, the logical element contains only an element type field and is to be ignored by the receiver of the information packet. The value is 4 plus the number of element bytes included up to the maximum value. The maximum length for any one interface logical element must be limited by the requirements of the currently negotiated maximum informa- tion packet length. The element type is a one-byte binary field. The valid values are defined in Table 6-5. +---------------------------------------------------------------------------+ | Table 6-5. ILE Element Type Codes | +---------------------------+-----------------------------------------------+ | ELEMENT TYPE VALUE | INTERFACE LOGICAL ELEMENT | +---------------------------+-----------------------------------------------+ | 0 | Message | +---------------------------+-----------------------------------------------+ | 1 | Command Descriptor Block | +---------------------------+-----------------------------------------------+ | 2 | Command Parameter Data | +---------------------------+-----------------------------------------------+ | 3 | Command Response Data | +---------------------------+-----------------------------------------------+ | 4 | Logical Block Data | +---------------------------+-----------------------------------------------+ | 5 | Status | +---------------------------+-----------------------------------------------+ | 6 | Autosense | +---------------------------+-----------------------------------------------+ | 7 - 255 | Reserved | +---------------------------+-----------------------------------------------+ The reserved field is a one-byte field. The sender shall set the field to zero. If the receiver of an information packet detects a value other than Section 6. SPP Information Packet Structure 6-7 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 zero it shall not process the logical element or any logical elements which follow in the same information packet. The logical element bytes field is a 0 to 65531 byte variable length field composed of the information about the element type declared in the element type field. The maximum length which may be used for this field may vary by the physical interface implemented. 6.1.2.1 Message Interface Logical Element The message interface logical element includes one or more complete messages and appppropriate for the physical bus implemented. A multiple byte message shall not be split into bursts. Each message ILE shall contain only one message. The element bytes are filled in with the message bytes in the order which they would be transferred on a single byte wide bus. 6.1.2.2 Command Descriptor Block Interface Logical Element The command descriptor block interface logical element is composed of the set of variable length CDBs for commands. Command parameter data is transferred in its own interface logical element. A command descriptor block shall not be split into bursts. Each CDB ILE shall contain only one CDB. The element bytes are filled in with the CDB bytes in the order which they would be transferred on a single byte wide bus. 6.1.2.3 Command Parameter Data Interface Logical Element The command parameter data interface logical element is a burst of data transferred for a command which is sent as an addendum to the command descriptor block. The CDB identifies the total length of the command param- eter data in the parameter length fields, etc. Each command parameter data ILE shall contain data for only one command. The element bytes are filled in with the command parameter data bytes in the order which they would be transferred on a single byte wide bus. 6.1.2.4 Command Response Data Interface Logical Element The command response data interface logical element is a burst of data trans- ferred from a target controller to an initiating controller for a command which is not taken from the logical blocks of the LUN. Sense data and MODE SENSE pages are examples of command response data. The CDB identifies the maximum length of the command response data in the allocation length fields, etc. Each command response data ILE shall contain data for only one command. The element bytes are filled in with the command response data bytes in the order which they would be transferred on a single byte wide bus. 6-8 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 6.1.2.5 Logical Block Data Interface Logical Element The logical block interface logical element consists of a burst of data from the logical blocks requested for transfer between an initiating controller and a target controller. Each logical block data ILE shall contain data for only one command. The element bytes are filled in with the bytes from a burst of data for one or more logical blocks in the order which they would be transferred on a single byte wide bus. The element length may vary. 6.1.2.6 Status Interface Logical Element The status interface logical element is the status value. Status shall not be split into bursts. Each Status ILE shall contain only one status code value. The element bytes are filled in with status in the order which they would be transferred on a single byte wide bus. 6.1.2.7 Autosense Interface Logical Element (Optional) The autosense interface logical element is the sense data for an I/O process which terminates with CA or ECA. Autosense shall not be split into bursts. Each autosense ILE shall contain data to report one event. The element bytes are filled in with sense data in the order which they would be transferred on a single byte wide bus. Section 6. SPP Information Packet Structure 6-9 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 6-10 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SECTION 7. SPP I/O PROCESS CONTROL ___________________________________ This section is divided into 2 parts: 1) Message descriptions; 2) Exception conditions. 7.1 MESSAGES (MANDATORY) _________________________ Messages allow communication of information between an initiating controller and target controller not contained in the other information packet contents (e.g., commands). The element bytes of a message interface logical element may be one, two, or multiple bytes in length. Zero or more messages may be transferred along with other interface logical elements in a single informa- tion packet. The initiating controller and target controller controller are required to control the content of information packets when it sends a message interface logical element in an information packet for certain messages as identified in Table 7-2 on page 7-2. The "Single Mesasge ILE in IP" column, when "YES" indicates the an information packet containing the message ILE shall be the only ILE in the information packet; no other ILE of any type shall be present in the information packet. The assigned ranges to messages and their lengths is defined in Table 7-1 on page 7-2. All SPP devices shall implement the mandatory messages tabulated in the "Init" column of Table 7-2 on page 7-2 for information packet operations. All SPP devices shall implement the mandatory messages tabulated in the "Targ" column of Table 7-2 on page 7-2 for information packet operations. This is modified by messages unique to the parallel interface. See the "-" prefix on the message name for these messages. One-byte, Two-byte, and extended message formats are defined. The first byte of the message determines the format as defined in Table 7-1 on page 7-2. Section 7. SPP I/O Process Control 7-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-1. Message Element Format Codes | +---------------------------+-----------------------------------------------+ | FORMAT CODE | MESSAGE ELEMENT BYTE FORMAT | +---------------------------+-----------------------------------------------+ | 00h | One-Byte Message (I/O PROCESS COMPLETE) | +---------------------------+-----------------------------------------------+ | 01h | Extended Messages | +---------------------------+-----------------------------------------------+ | 02h - 1Fh | One-Byte Messages | +---------------------------+-----------------------------------------------+ | 20h - 2Fh | Two-Byte Messages | +---------------------------+-----------------------------------------------+ | 30h - 7Fh | Reserved | +---------------------------+-----------------------------------------------+ | 80h - FFh | Reserved Messages | +---------------------------+-----------------------------------------------+ One-byte messages consist of a single byte where the value of the byte deter- mines which function is to be performed as defined in Table 7-2. Two byte messages consist of a message code followed by a parameter byte. The message code determines which function is to be performed using the value in the parameter byte. A value of 01h in the first byte of a message indicates the beginning of a multiple-byte extended message. The minimum number of bytes in an extended message is three. The maximum number of bytes in an extended message is 258 bytes. The extended message codes and the extended message format are shown in Table 7-4 on page 7-5 and Table 7-3 on page 7-4, respectively. +---------------------------------------------------------------------------+ | Table 7-2 (Page 1 of 3). Message Codes | +---------+---------+-----------------------------------+---------+---------+ | CODE | SUPPORT | MESSAGE NAME | DIREC- | SINGLE | | | INIT | | TION | MESSAGE | | | TARG | | | ILE IN | | | | | | IP | +---------+----+----+-----------------------------------+----+----+---------+ | 06h | O | M | ABORT | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 0Dh | O | M | ABORT I/O PROCESS | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 0Ch | O | M | BUS DEVICE RESET | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 0Eh | O | M | CLEAR QUEUE | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 00h | M | M | I/O PROCESS COMPLETE | In | | No | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | EXTENDED MESSAGE REJECT | In | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 0Fh | M | O | INITIATE RECOVERY | In | | No | +---------+----+----+-----------------------------------+----+----+---------+ 7-2 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-2 (Page 2 of 3). Message Codes | +---------+----+----+-----------------------------------+----+----+---------+ | 0Fh | M | O | INITIATE RECOVERY (Note 1) | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | -INVALID BUS PHASE DETECTED | In | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | INVALID INFORMATION PACKET | In | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 0Ah | M | M | LINKED COMMAND COMPLETE | In | | No | +---------+----+----+-----------------------------------+----+----+---------+ | 0Bh | M | M | LINKED COMMAND COMPLETE (with | In | | No | | | | | Flag) | | | | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | MODIFY DATA POSITION | In | | No | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | -PARITY ERROR | In | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 10h | M | O | RELEASE RECOVERY | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | RESEND PREVIOUS INFORMATION | In | Out| Yes | | | | | PACKET | | | | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | -SYNCHRONOUS DATA TRANSFER | In | Out| Yes | | | | | REQUEST | | | | +---------+----+----+-----------------------------------+----+----+---------+ | *** | M | M | SYNCHRONOUS PACKET TRANSFER | In | Out| Yes | | | | | REQUEST | | | | +---------+----+----+-----------------------------------+----+----+---------+ | 11h | O | M | TERMINATE I/O PROCESS | | Out| Yes | +---------+----+----+-----------------------------------+----+----+---------+ | 12h | M | M | TRANSFER READY | In | | No | +---------+----+----+-----------------------------------+----+----+---------+ | 02h- | | | Reserved If Not Listed Above | | | | | 1Fh | | | | | | | +---------+----+----+-----------------------------------+----+----+---------+ | 20h- | | | Reserved for Two-Byte Messages | | | | | 2Fh | | | | | | | +---------+----+----+-----------------------------------+----+----+---------+ | 30h- | | | Reserved | | | | | 7Fh | | | | | | | +---------+----+----+-----------------------------------+----+----+---------+ | 80h- | | | Reserved | | | | | FFh | | | | | | | +---------+----+----+-----------------------------------+----+----+---------+ Section 7. SPP I/O Process Control 7-3 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-2 (Page 3 of 3). Message Codes | +---------------------------------------------------------------------------+ | | | | | | | Key: M = Mandatory support, O = Optional support. | | Targ = Target Controller | | Init = Initiating Controller | | ILE = Interface Logical Element | | IP = Information Packet | | In = Target to initiator, Out = Initiator to target. | | Yes = IP has Single Message ILE and no other ILEs | | No = May be other ILEs in IP | | - = SPI implementations only. | | *** = Extended message Code Value (see Tables Table 7-4 on page |-5) | | | NOTES: | | | | (1) Outbound INITIATE RECOVERY message is only valid during the | | extended contingent allegiance protocol started | | with asynchronous event notification. | +---------------------------------------------------------------------------+ The extended message length specifies the length in bytes of the extended message code plus the extended message arguments to follow. Therefore, the total length of the message is equal to the extended message length plus two. A value of zero for the extended message length indicates 256 bytes follow. +---------------------------------------------------------------------------+ | Table 7-3. Extended Message Element Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | n | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | - | Extended Message Code (Table 7-4 on page 7-5) | +-----------+------------+--------------------------------------------------+ | 3 - n+1 | - | Extended Message Parameters | +-----------+------------+--------------------------------------------------+ The extended message codes are listed in Table 7-4 on page 7-5. The extended message arguments are specified with each extended message description. For extended messages, the message code is followed by a variable length set of zero or more parameter bytes. The function to be performed is determined by the value in the Extended Message Code field. 7-4 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-4. Extended Message Codes | +---------------------------+-----------------------------------------------+ | CODE VALUE | NAME | +---------------------------+-----------------------------------------------+ | | (Ordered by Extended Message Name) | | | | | | | +---------------------------+-----------------------------------------------+ | 04h | EXTENDED MESSAGE REJECT | +---------------------------+-----------------------------------------------+ | 02h | INVALID BUS PHASE DETECTED (Parallel Only) | +---------------------------+-----------------------------------------------+ | 06h | INVALID INFORMATION PACKET | +---------------------------+-----------------------------------------------+ | 00h | MODIFY DATA POSITION | +---------------------------+-----------------------------------------------+ | 03h | PARITY ERROR (Parallel Only) | +---------------------------+-----------------------------------------------+ | 05h | RESEND PREVIOUS INFORMATION PACKET | +---------------------------+-----------------------------------------------+ | 01h | SYNCHRONOUS DATA TRANSFER REQUEST (Parallel On|y) +---------------------------+-----------------------------------------------+ | 07h | SYNCHRONOUS PACKET TRANSFER REQUEST | +---------------------------+-----------------------------------------------+ | 08h - 7Fh | Reserved | +---------------------------+-----------------------------------------------+ | 80h - FFh | Reserved | +---------------------------+-----------------------------------------------+ | | (Ordered by Extended Message Code) | | | | | | | +---------------------------+-----------------------------------------------+ | 00h | MODIFY DATA POSITION | +---------------------------+-----------------------------------------------+ | 01h | SYNCHRONOUS DATA TRANSFER REQUEST (Parallel On|y) +---------------------------+-----------------------------------------------+ | 02h | INVALID BUS PHASE DETECTED (Parallel Only) | +---------------------------+-----------------------------------------------+ | 03h | PARITY ERROR (Parallel Only) | +---------------------------+-----------------------------------------------+ | 04h | EXTENDED MESSAGE REJECT | +---------------------------+-----------------------------------------------+ | 05h | RESEND PREVIOUS INFORMATION PACKET | +---------------------------+-----------------------------------------------+ | 06h | INVALID INFORMATION PACKET | +---------------------------+-----------------------------------------------+ | 07h | SYNCHRONOUS PACKET TRANSFER REQUEST | +---------------------------+-----------------------------------------------+ | 08h - 7Fh | Reserved | +---------------------------+-----------------------------------------------+ | 80h - FFh | Reserved | +---------------------------+-----------------------------------------------+ Section 7. SPP I/O Process Control 7-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 SPP messages are defined below. The requirements for message implementation are given in Table 7-2 on page 7-2. Additional messages shall be implemented when certain SPP functions are implemented. These messages are identified in Table 7-2 on page 7-2 for information packets and in the message descriptions. 7.1.1 ABORT The ABORT message is sent from the initiating controller to the target con- troller to clear the identified I/O process plus any active or queued I/O processes for the H_C_x_y nexus. Pending data, status, and queued I/O proc- esses for any other H_C_x_y nexus shall not be cleared. The information packet containing an ABORT message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the ABORT message. If only an H_C nexus has been established, no status or message shall be sent for the current I/O process and no other I/O process shall be affected. It is not an error to issue this message to a logical unit or target routine that does not have any active or queued I/O processes. Previously established conditions, including MODE SELECT parameters, reserva- tions, and extended contingent allegiance shall not be changed by the ABORT message. 7.1.2 ABORT I/O PROCESS The target controller shall clear the I/O process identified. If the target controller has already started execution of the I/O process, execution shall be halted. The medium contents may have been modified before the information packet was processed. In either case, any pending status or data for the I/O process shall be cleared and no additional ILEs shall be sent to the initi- ating controller. The information packet containing an ABORT I/O PROCESS message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the ABORT I/O PROCESS message. Pending status, data, and commands for other active or queued I/O processes shall not be affected. Execution of other I/O processes shall not be aborted. Previously established conditions, including MODE SELECT parameters, reserva- tions, and extended contingent allegiance shall not be changed by the ABORT I/O PROCESS message. It is not an error to issue this message to a logical unit or target routine that does not have any active or queued I/O processes. 7-6 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.1.3 BUS DEVICE RESET The BUS DEVICE RESET message is sent from an initiating controller to direct a target controller to clear all I/O processes on that SPP device. This message forces a reset condition to the selected SPP device. The target con- troller shall create a unit attention condition for all initiating control- lers. The information packet containing an BUS DEVICE RESET message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the BUS DEVICE RESET message. 7.1.4 CLEAR QUEUE The target controller shall perform an action equivalent to receiving a series of ABORT messages from each initiating controller. All I/O processes, from all initiating controllers, in the queue for the specified logical unit or target routine shall be cleared from the queue. All active I/O processes shall be terminated. The medium may have been altered by partially executed commands. The information packet containing an CLEAR QUEUE message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the CLEAR QUEUE message. All pending status and data for that logical unit or target routine for all initiating controllers shall be cleared. No status or message shall be sent for any of the I/O processes. A unit attention condition shall be generated for all other initiating controllers with I/O processes that either were active or were queued for that logical unit or target routine. When reporting the unit attention condition the additional sense code shall be set to COMMANDS CLEARED BY ANOTHER INITIATOR. Previously established conditions, including MODE SELECT parameters, reservations, and extended contingent alle- giance shall not be changed by the CLEAR QUEUE message. 7.1.5 I/O PROCESS COMPLETE The I/O PROCESS COMPLETE message is sent from a target controller to an ini- tiating controller to indicate that the execution of an I/O process has com- pleted and that valid status has been sent to the initiating controller. The I/O process may have completed successfully or unsuccessfully as indicated by the status value. Section 7. SPP I/O Process Control 7-7 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.1.6 EXTENDED MESSAGE REJECT The EXTENDED MESSAGE REJECT message (Table 7-5 on page 7-8) is sent from either the initiating controller or target controller to indicate that a portion of a message in a message interface logical element in the last information packet was inappropriate or has not been implemented. The content of the extended message identifies the message group and the message byte within the group. The message also indicates the reason for the rejection. This provides a logical interlock so that the receiver of the message can determine which message byte is in error. The information packet containing an EXTENDED MESSAGE REJECT message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the EXTENDED MESSAGE REJECT message. +---------------------------------------------------------------------------+ | Table 7-5. EXTENDED MESSAGE REJECT Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 04h | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 04h | Extended Message Code | +-----------+------------+--------------------------------------------------+ | 3 | x | ILE Position | +-----------+------------+--------------------------------------------------+ | 4 | x | Message Position in ILE | +-----------+------------+--------------------------------------------------+ | 5 | x | Byte Position in Message | +-----------+------------+--------------------------------------------------+ | 6 | x | Reject Reason Code | +-----------+------------+--------------------------------------------------+ | 7 | 00h | Reserved | +-----------+------------+--------------------------------------------------+ The ILE Position is the ordinal position of the message interface logical element within the information packet containing the error. The ILE Position is a value between 1 to 255. There may be more than one message interface logical element in one information packet. The Message Position in ILE is the message possition of the message in error within the ILE. The value is 0 for the first message in the ILE. The range is 0 - 255. The Byte Position in ILE is the byte position of the byte in error within the element bytes of the message in error. The value is 0 for the first message in the ILE. The range is 0 - 255. 7-8 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 The Reject Reason Code identifies the reason for sending the message. A code of 00h indicates that the message code in a one-byte, two-byte, or extended message is not implemented. A code of 01h indicates that the message is inappropriate. A code of 02h indicates that the length byte in an extended message is invalid for the message code. A code of 03h indicates that a parameter byte within two-byte and extended messages is invalid. Codes 04h-FFh are reserved. 7.1.7 INITIATE RECOVERY The INITIATE RECOVERY message shall be implemented by a tareget controller if extended contingent allegiance is implemented. A target controller that supports extended contingent allegiance shall inform the initiating controller it is entering this condition by sending an INI- TIATE RECOVERY message immediately following a CHECK CONDITION or I/O PROCESS TERMINATED status. The extended contingent allegiance condition remains in effect until terminated as described in 6.12. If an asynchronous event occurs, the target controller may enter an extended contingent allegiance condition by becoming a temporary initiating controller and sending the INITIATE RECOVERY message followed by the SEND COMMAND that is used to perform asynchronous event notification (see 6.6). The successful transmission of this message establishes the extended contingent allegiance condition in the initiating controller which remains in effect until termi- nated as described in 6.12. If the target controller notifies multiple initiating controllers of the asynchronous event, it may include the INITIATE RECOVERY message in each notification, depending on the target controllers ability to manage recovery by multiple initiating controllers (e.g., a buffered mode setting of 2 for sequential access devices). When this message is sent outbound, the initiating controller is indicating that it is entering extended contingent allegiance with the target controller as a result of a asynchronous event notification that contained a message interface logical element with the INITIATE RECOVERY message. The informa- tion packet containing an INITIATE RECOVERY message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the INITIATE RECOVERY message. 7.1.8 INVALID BUS PHASE DETECTED (PARALLEL) Section 7. SPP I/O Process Control 7-9 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-6. INVALID BUS PHASE DETECTED Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 02h | Estended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 02h | Extended Message Code | +-----------+------------+------+-----+-----+------+-----+------+-----+-----+ | 3 | x | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | | | 0b | 0b | 0b | 0b | 0b | Msg | C/D | I/O | +-----------+------------+------+-----+-----+------+-----+------+-----+-----+ The INVALID BUS PHASE DETECTED message (Table 7-6) is sent from either logical element to the other to inform it that an illegal or reserved bus phase was detected on a parallel interface. The information packet containing an INVALID BUS PHASE DETECTED message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the INVALID BUS PHASE DETECTED message. The Msg bit shall contain 1 if the phase where the phase error was detected has the MSG signal set to true. Otherwise, the Msg bit shall be set to zero. The C/D bit shall contain 1 if the phase where the phase error was detected has the C/D signal set to true. Otherwise, the C/D bit shall be set to zero. The I/O bit shall contain 1 if the phase where the phase error was detected has the I/O signal set to true. Otherwise, the I/O bit shall be set to zero. The three bits identify the phase code which was detected in error. 7.1.9 INVALID INFORMATION PACKET The INVALID INFORMATION PACKET message (Table 7-7 on page 7-11) is sent from either the initiating controller or target controller in an information packet to indicate that all or a portion of an information packet transferred was invalid. The format of the information packet does not conform to the rules for information packet construction. Errors in the content of the element bytes of interface logical elements is not pointed to using this message; see sense data. The information packet containing an INVALID INFORMATION PACKET message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the INVALID INFORMATION PACKET message. 7-10 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-7. INVALID INFORMATION PACKET Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 05h | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 06h | Extended Message Code | +-----------+------------+--------------------------------------------------+ | 3 | x | ILE Position | +-----------+------------+--------------------------------------------------+ | 4 | x | Reason Code | +-----------+------------+--------------------------------------------------+ | 5 - 6 | xxxxh | (MSB) | | | | Relative Position | | | | (LSB) | +-----------+------------+--------------------------------------------------+ The ILE Position is the ordinal position of the interface logical element group within the information packet containing the error. The ILE Position is a value between 1 to 255. There may be more than one message interface logical element in each information packet. A value of 0 in ILE Position indicates that the information control prefix or suffix fields are in error. The Reason Code identifies the reason for sending the message. A code of 00h indicates that the interface logical element type in a descriptor is invalid. A code of 01h indicates that the interface logical element length field is invalid. Codes 02h-FFh are reserved. The Relative Position identifies the byte position of the field or bit in error. The exact bit position is not provided. The value gives the relative position of the byte to the beginning of the ILE when the ILE Number value is 1 to 255. The value gives the relative position of the byte to the beginning of the information packet when the ILE Number value is zero. 7.1.10 LINKED COMMAND COMPLETE The LINKED COMMAND COMPLETE message is sent from a target controller to an initiating controller to indicate that the execution of a linked command has completed and that status has been sent. The next command may come from the active I/O process queue as part on an information packet already transferred or it comes from the initiating controller in a new information packet. Section 7. SPP I/O Process Control 7-11 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.1.11 LINKED COMMAND COMPLETE (WITH FLAG) The LINKED COMMAND COMPLETE (WITH FLAG) message is sent from a target con- troller to an initiating controller to indicate that the execution of a linked command (with the flag bit set to one) has completed and that status has been sent. The next command may come from the active I/O process queue as part on an information packet already transferred or it comes from the initiating controller in a new information packet. 7.1.12 MODIFY DATA POSITION +---------------------------------------------------------------------------+ | Table 7-8. MODIFY DATA POSITION Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 05h | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 00h | Extended Message Code | +-----------+------------+--------------------------------------------------+ | 3 - 6 | xxxxxxxxh | (MSB) | | | | Change in Relative Position | | | | (LSB) | +-----------+------------+--------------------------------------------------+ The MODIFY DATA POSITION message (Table 7-8) requests that the signed argu- ment be added (two's complement) to the value of the current logical block position in the initiating controller. This message shall control or adjust the logical block data transfer position for a current I/O process. If the change in relative position added to the current initiating controller results in a value less than zero or greater than the total length for the command, the initiating controller shall .... 7.1.13 PARITY ERROR (PARALLEL) +---------------------------------------------------------------------------+ | Table 7-9. PARITY ERROR Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 02h | Estended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 03h | Extended Message Code | +-----------+------------+------+-----+-----+------+-----+------+-----+-----+ | 3 | x | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | | | 0b | 0b | 0b | 0b | 0b | Msg | C/D | I/O | +-----------+------------+------+-----+-----+------+-----+------+-----+-----+ 7-12 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 The PARITY ERROR message is sent from either logical element to the other to inform it that a parity error was detected during an information packet transfer on a parallel interface. The information packet containing an ABORT I/O PROCESS message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the ABORT I/O PROCESS message. Table 7-9 on page 7-12. defines the format for the parity error message. The Msg bit shall contain 1 if the invalid phase detected has the MSG signal set to true. Otherwise, the Msg bit shall be set to zero. The C/D bit shall contain 1 if the invalid phase detected has the C/D signal set to true. Otherwise, the C/D bit shall be set to zero. The I/O bit shall contain 1 if the invalid phase detected has the I/O signal set to true. Otherwise, the I/O bit shall be set to zero. The three bits identify the phase where the parity error was detected. 7.1.14 RELEASE RECOVERY The RELEASE RECOVERY message shall be implemented if extended contingent allegiance is implemented. The RELEASE RECOVERY message is sent from an initiating controller to a target controller to terminate an extended contingent allegiance condition previously established by an INITIATE RECOVERY message. The extended contin- gent allegiance condition ends on successful processing of the RELEASE RECOVERY message. The information packet containing an RELEASE RECOVERY message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the RELEASE RECOVERY message. If a RELEASE RECOVERY message is received by a target controller that imple- ments extended contingent allegiance when no extended contingent allegiance condition is active, the message shall not be rejected. The message shall be ignored. 7.1.15 RESEND PREVIOUS INFORMATION PACKET Section 7. SPP I/O Process Control 7-13 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-10. RESEND PREVIOUS INFORMATION PACKET Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 02h | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 05h | Extended Message Code | +-----------+------------+--------------------------------------------------+ | 3 | xxh | Previous Packet Number | +-----------+------------+--------------------------------------------------+ The RESEND PREVIOUS INFORMATION PACKET message (Table 7-10) is sent by an initiating controller or a target controller to indicate that a previous information packet must be resent. The synchronous packet transfer request negotiation has produced an agreement for the maximum number of packets to be retained by both the initiating controller and the target controller. A value of zero in the previous packet number field causes the device to resend the last information packet transferred. Values of 1 through 255 rep- resent the 2nd to 256th most recent packets transmitted. It shall be an error for a device to transmit a value in this field which is larger than the limit negotiated using the SYNCHRONOUS PACKET TRANSFER REQUEST message. The information packet containing an RELEASE RECOVERY message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the RELEASE RECOVERY message. 7.1.16 SYNCHRONOUS DATA TRANSFER REQUEST (PARALLEL) +---------------------------------------------------------------------------+ | Table 7-11. SYNCHRONOUS DATA TRANSFER REQUEST Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 03h | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 01h | Extended Message Code | +-----------+------------+--------------------------------------------------+ | 3 | xxh | Transfer Period (m times 4 nanoseconds) | +-----------+------------+--------------------------------------------------+ | 4 | xxh | REQ/ACK Offset | +-----------+------------+--------------------------------------------------+ (Rework like SPTR. GRS) A SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) message (Table 7-11) exchange shall be initiated by an SPP device whenever a previously-arranged data 7-14 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 transfer agreement may have become invalid. The agreement becomes invalid after any condition which may leave the data transfer agreement in an inde- terminate state such as: (1) after a reset event (2) after a BUS DEVICE RESET message and (3) after a power cycle. The information packet containing an SYNCHRONOUS DATA TRANSFER REQUEST message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the SYNCHRONOUS DATA TRANSFER REQUEST message. The SDTR message exchange establishes the permissible transfer periods and the REQ/ACK offsets for all logical units and target routines on the two devices. This agreement only applies to the information transfer phases. The transfer period is the minimum time allowed between leading edges of suc- cessive REQ pulses and of successive ACK pulses to meet the device require- ments for successful reception of data. The REQ/ACK offset is the maximum number of REQ pulses allowed to be out- standing before the leading edge of its corresponding ACK pulse is received at the target controller. This value is chosen to prevent overflow conditions in the device's reception buffer and offset counter. A REQ/ACK offset value of zero shall indicate asynchronous data transfer mode; a value of FFh shall indicate unlimited REQ/ACK offset. The originating device (the device that sends the first of the pair of SDTR messages) sets its values according to the rules above to permit it to receive data successfully. If the responding device can also receive data successfully with these values (or smaller transfer periods or larger REQ/ACK offsets or both), it returns the same values in its SDTR message. If it requires a larger transfer period, a smaller REQ/ACK offset, or both to receive data successfully, it substitutes values in its SDTR message as required, returning unchanged any value not required to be changed. Each device when transmitting data shall respect the limits set by the other's SDTR message, but it is permitted to transfer data with larger transfer periods, smaller REQ/ACK offsets, or both than specified in the other's SDTR message. The successful completion of an exchange of SDTR messages implies an agreement, retainec by both the initiating controller and target con- troller, as follows: Section 7. SPP I/O Process Control 7-15 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 RESPONDING DEVICE SDTR RESPONSE IMPLIED AGREEMENT ------------------------------- ------------------------------------------- (1) NON-ZERO REQ/ACK OFFSET EACH DEVICE TRANSMITS DATA WITH A TRANSFER PERIOD EQUAL TO OR GREATER THAN AND A REQ/ACK OFFSET EQUAL TO OR LESS THAN THE VALUES RECEIVED IN THE OTHER DEVICE'S SDTR MESSAGE. (2) REQ/ACK OFFSET EQUAL TO ZERO ASYNCHRONOUS TRANSFER (3) UNEXPECTED DISCONNECT ASYNCHRONOUS TRANSFER (4) PARITY ERROR ASYNCHRONOUS TRANSFER If a logical element recognizes that negotiation is required, it asserts it sends a SDTR message to begin the negotiating process. The other logical element shall respond with the proper SDTR message. If an abnormal condition prevents the target controller from returning an appropriate response, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. Following the second logical element resoponse of (1) above, the implied agreement for synchronous operation shall be considered to be negated by both the initiating controller and the target controller if the first logical element sends as the first message a MESSAGE PARITY ERROR (thrid message of sequence). In this case, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. For the PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of a pair of messages is successful. After a vendor-specific number of retry attempts (greater than zero), if the second logical element receives a PARITY ERROR message, it shall terminate the retry activity. The initiating con- troller shall accept such action as aborting the negotiation, and both devices shall go to asynchronous data transfer mode for data transfers between the two devices. Following an initiating controller's responding SDTR message, an impli ed agreement for synchronous operation shall not be considered to exist until the target controller leaves the MESSAGE OUT phase, indicating that the target controller has accepted the negotiation. The implied synchronous agreement shall remain in effect until a BUS DEVICE RESET message is received, until a hard reset condition occurs, or until one of the two SPP devices elects to modify the agreement. The default data transfer mode is asynchronous data transfer mode. The default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or after a hard reset condition. 7.1.17 SYNCHRONOUS PACKET TRANSFER REQUEST 7-16 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +---------------------------------------------------------------------------+ | Table 7-12. SYNCHRONOUS PACKET TRANSFER REQUEST Message Format | +-----------+------------+--------------------------------------------------+ | BYTE | VALUE | DESCRIPTION | +-----------+------------+--------------------------------------------------+ | 0 | 01h | Extended Message Format Code | +-----------+------------+--------------------------------------------------+ | 1 | 03h | Extended Message length | +-----------+------------+--------------------------------------------------+ | 2 | 07h | Extended Message Code | +-----------+------------+--------------------------------------------------+ | 3 | xxh | Packet Offset Count | +-----------+------------+--------------------------------------------------+ | 4-5 | xxxxh | Maximum Information Packet Length | +-----------+------------+--------------------------------------------------+ A SYNCHRONOUS PACKET TRANSFER REQUEST (SPTR) message (Table 7-12) exchange shall be initiated by an SPP device whenever a previously arranged packet transfer agreement may have become invalid. Each SPP device shall be able to retain at minimum one information packet per I/O process for retransmission (i.e., the last information packet successfully transferred in each direc- tion). Each SPP device shall be able to support information packet lengths of 256 bytes or larger. The information packet containing an SYNCHRONOUS PACKET TRANSFER REQUEST message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the SYNCHRONOUS PACKET TRANSFER REQUEST message. In the absence of an explicit packet offset count agreement for value larger than one, the implied packet offset count agreement shall be 1 for both ini- tiating controllers and target controllers. At the end of an exchange, both the initiating controller and target controller agree to maintain, for retransmitting only, a minimum number of information packets (greater than or equal to one). The packet offset count represents n+1 information packets that the initi- ating controller or target controller declares that it can retain at maximum or has agreed upon with another SPP device. A maximum of 256 information packets may be retained per I/O process at the end of an SPTR negotiation. For initiating controllers which implement the MODIFY DATA POSITION message, there may be an additional requirement to retain additional information packets. In the absence of an explicit maximum information packet length agreement for value larger than 256, the implied maximum information packet length agree- ment shall be 256 for both initiating controllers and target controllers. At the end of an exchange, both the initiating controller and target controller agree to maintain buffers for information packets of at least the negotiated size. The synchronous packet transfer agreement becomes invalid after any condition which may leave the packet transfer agreement in an indeterminate state such as: Section 7. SPP I/O Process Control 7-17 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 (1) after a hard reset condition (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SPP device may initiate an SPTR message exchange whenever it is appropriate to negotiate a new packet transfer agreement. The SPTR message exchange establishes the minimum number of information packets that the initiating controller and target controller shall maintain to permit retransmitting in case of physical or logical errors in information packets. This agreement only applies to information packets. See the RESENT PREVIOUS INFORMATION PACKET message. The originating device (the device that sends the first of the pair of SDTR messages) sets its values according to its capabilities to retain information packets on a per I/O process basis. If the responding device can also retain information packets at this level, it returns the same values in its SPTR message. If it requires a smaller retention count, it substitutes a lower value in its SPTR message. The originating device analyzes the response and may initiate another SPTR message with the same or a still lower value. The negotiation shall end when both devices exchange the same value or the value reaches 1, whichever occurs first. Each device shall retain the number of information packets for retransmit- ting, as agreed upon in the most recent SPTR exchange or one, whichever is larger. If there is any error in the negotiation process, the agreement shall be 1 after the I/O process. 7.1.18 TERMINATE I/O PROCESS The TERMINATE I/O PROCESS message is sent from the initiating controller to the target controller to advise the target controller to terminate the current I/O process without corrupting the medium. Upon successful receipt of this message the target controller shall terminate the identified I/O process as soon as possible and return I/O PROCESS TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qual- ifier shall be set to I/O PROCESS TERMINATED. The TERMINATE I/O PROCESS message shall not affect pending status, data, and commands for other queued or active I/O processes. However, continued execution and status of other I/O processes queued for the H_C_x_y nexus may be affected by the queue error recovery option specified in the control mode page parameters. The information packet containing an TERMINATE I/O PROCESS message shall contain only one interface logical element, a message interface logical element. The message interface logical element shall contain only one message, the TERMINATE I/O PROCESS message. If the I/O process that is being terminated has a data transfer associated with it, the valid bit in the sense data shall be set to one and the informa- tion field shall be set as follows: (1) If the command descriptor block 7-18 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 specifies an allocation length or parameter list length in bytes, the infor- mation field shall be set to the difference (residue) between the transfer length and the number of bytes successfully transferred. (2) If the command descriptor block specifies a transfer length field, the information field shall be set as defined in the REQUEST SENSE command. If the I/O process being terminated has no data transfer associated with it the target controller shall set the valid bit in the sense data to zero and terminate the I/O process with I/O PROCESS TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. When any error condition is detected while terminating an I/O process the target controller shall ignore the TERMINATE I/O PROCESS message and termi- nate the I/O process with the appropriate error status and sense data for the error condition. If the target controller completes all processing for a command (i.e., all data has been read, written, or processed) and a TERMINATE I/O PROCESS message is received before the I/O process is terminated, the target con- troller shall ignore the TERMINATE I/O PROCESS message and terminate the I/O process in the normal manner. If the target controller receives a TERMINATE I/O PROCESS message before the command descriptor block is transferred or the message is issued to an H_C_x nexus that does not have an active or queued I/O process, the target con- troller shall set the valid bit in the sense data to zero and terminate the I/O process with I/O PROCESS TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. If the affected I/O process is in the command queue (an H_C_x nexus for untagged queuing or an H_C_L_Q nexus for tagged queuing) and has not started execution, the target controller shall record the event with the queued I/O process and wait until the command is in the active queue (started executing) then terminate the I/O process. The target controller shall terminate the I/O process with I/O PROCESS TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. The valid bit shall be set to zero. The TERMINATE I/O PROCESS message provides a means for the initiating con- troller to request the target controller to reduce the transfer length of the current command to the amount that has already been transferred. The initi- ating controller can use the sense data to determine the actual number of bytes or blocks that have been transferred. IMPLEMENTORS NOTE: This message is normally used by the initiating con- troller to stop a lengthy read, write, or verify operation when a higher priority command is available to be executed. It is up to the initiating controller to complete the terminated command at a later time, if required. Section 7. SPP I/O Process Control 7-19 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.1.19 TRANSFER READY The TRANSFER READY message is sent to indicate that an active I/O process requires additional information packets. The message is used to direct an initiating controller to continue sending information packets for the identi- fied I/O process. No equivalent message is needed for operations which send logical block data or command response data to an initiating controller. The target controller picks the path it wants to use based on agreements with the initiating con- troller for the I/O process and sends the information packets. 7-20 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.2 COMMAND PROCESSING CONSIDERATIONS AND EXCEPTION CONDITIONS _______________________________________________________________ The following sections describe some exception conditions and errors associ- ated with command processing and the sequencing of commands. 7.2.1 UNIT ATTENTION CONDITION The target shall generate a unit attention condition for each initiator on each valid logical unit whenever the target has been reset by a BUS DEVICE RESET message, a hard reset condition, or by a power-on reset. The target shall also generate a unit attention condition on the affected logical unit(s) for each initiating controller whenever one of the following events occurs: (1) A removable medium may have been changed. (2) The mode parameters in effect for this initiating controller have been changed by another initiating controller. (3) The version or level of microcode has been changed. (4) Tagged commands queued for this initiating controller were cleared by another initiating controller. (5) INQUIRY data has been changed. (6) The mode parameters in effect for this initiating controller have been restored from nonvolatile memory. (7) A change in the condition of a synchronized spindle. (8) Any other event occurs that requires the attention of the host system. The unit attention condition shall persist on the logical unit for each ini- tiating controller until that initiating controller clears the condition as described in the following paragraphs. If the target controller has no active I/O process for an initiating con- troller, the unit attention condition shall be reported using asynchronous event notification to each initiating controller. If each SEND command com- pletes with GOOD status, this report clears the unit attention condition for each initiating controller for which AEN has been reported. The remainder of this discussion relates to events which occur in a target controller from detection of the event until the target controller reports the unit attention using AEN. This dicsussion describes actions which take place in this interval of time. If the following procedures are used, the unit attention has been reported and AEN is not required (unit attention is reported only once per event per initiating controller). If an INQUIRY command is received from an initiating controller to a logical unit with a pending unit attention condition (before the target generates the Section 7. SPP I/O Process Control 7-21 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 AEN), the target shall perform the INQUIRY command and shall not clear the unit attention condition. If the INQUIRY command is received after the target has generated the AEN, the unit attention condition on the logical unit has been cleared; and the target shall perform the INQUIRY command. If a command is received while preparing a unit attention AEN, other than the INQUIRY command, the target controller shall terminate the command with a contingent allegiance condition with sense key of UNIT ATTENTION. If the sense data is supplied as autosense, the contingent allegiance is cleared and the unit attention condition is also cleared. If autosense is not supplied with the CHECK CONDITION status, if any other command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, the unit attention condi- tion on the logical unit shall be cleared. If no other unit attention condi- tion is pending the target shall perform the command. If another unit attention condition is pending the target shall not perform the command and shall generate another contingent allegiance condition. If a REQUEST SENSE command is received from an initiator with a pending unit attention condition (before the target generates the AEN or establishes a contingent allegiance condition), the target controller shall report any pending sense data and preserve the unit attention condition on the logical unit. If the target has already generated the contingent allegiance condition for the unit attention condition, the target shall report the unit attention con- dition and preserve any other pending sense data for a subsequent contingent allegiance or AEN. If an initiator issues a command other than INQUIRY or REQUEST SENSE while a unit attention condition exists for that initiator (prior to reporting it with AEN or generating the contingent allegiance condition for the unit attention condition), the target shall not perform the command and shall report CHECK CONDITION status unless a higher priority status as defined by the target controller is also pending (e.g., BUSY or RESERVATION CONFLICT). If after generating the contingent allegiance condition for a pending unit attention condition, the next command received from that initiator on the logical unit is not REQUEST SENSE, then that command shall be performed and the unit attention condition shall be cleared for that initiator on the logical unit and the sense data is lost (see 6.6). IMPLEMENTORS NOTES: (1) Targets may queue unit attention conditions on logical units. After the first unit attention condition is cleared, another unit attention con- dition may exist (e.g., a power on condition followed by a microcode change condition). The initiating controller can clear all pending unit attention conditions by repeatedly sending the REQUEST SENSE command until a sense key other than UNIT ATTENTION is returned by the target. 7-22 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.2.2 INCORRECT INITIATING CONTROLLER CONNECTION An incorrect initiating controller connection occurs on an initial connection when an initiator: (1) attempts to establish an H_C_L_Q nexus when an H_C_L nexus already exists from a previous connection for the same H, C, and L values, or (2) attempts to establish an H_C_L nexus when an H_C_L_Q nexus already exists unless there is a contingent allegiance or extended contingent allegiance condition present for the logical unit or target routine. A target controller that detects an incorrect initiator connection shall abort terminate all I/O processes for the initiating controller with contin- gent allegiance. The sense key shall be set to ABORTED COMMAND and the addi- tional sense code shall be set to OVERLAPPED I/O PROCESSES ATTEMPTED. (Section 7 Update. GRS) Other sense data appropriate for the condition is included in the sense data (e.g., number of blocks not processed). If the target controller requires a significant recovery action, it may use extended contingent allegiance rather than contingent allegiance when reporting the error. 7.2.3 I/O PROCESSES FOR AN INVALID LUN OR TRN The target controller response to an I/O process directed to an invalid LUN or TRN is described in the following paragraphs. The LUN oir TRN may not be valid because: (1) the target controller does not support the logical unit number. In response to an INQUIRY command the target controller shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to any other command except REQUEST SENSE the target controller shall terminate the command with contingent allegiance. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED. (2) the target controller supports the logical unit, but the peripheral device is not currently attached to the target controller. In response to an INQUIRY command the target controller shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to a REQUEST SENSE command the target controller shall return the sense data with a sense key of NO SENSE to indicate that the LUN or TRN is supported. In response to any other command the target shall terminate the command with contingent allegiance. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT OPERATIONAL. (Update section 7. GRS) (path group and assignment considerations? GRS (3) the target controller supports the logical unit and the peripheral device is attached, but not operational. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to a REQUEST SENSE command the target controller shall return the sense data with a sense key of NO SENSE to Section 7. SPP I/O Process Control 7-23 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 indicate that the LUN or TRN is supported. In response to any other command the target shall terminate the command with contingent allegiance. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT OPERATIONAL. (path group and assignment consider- ations? GRS (4) the target supports the logical unit but is incapable of determining if the peripheral device is attached or is not operational when it is not ready. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to a REQUEST SENSE command In response to a REQUEST SENSE command the target controller shall return the sense data with a sense key of NO SENSE to indicate that the LUN or TRN is supported. In response to any other command the target shall terminate the command with contingent allegiance. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT OPERATIONAL. (path group and assignment considerations? GRS 7.2.4 PARAMETER ROUNDING range of values. target controllers may choose to implement only selected values from this range. When the target controller receives a value that it does not support, it either rejects the command (CHECK CONDITION status with ILLEGAL REQUEST sense key) or it rounds the value received to a supported value. The target controller shall reject unsupported values unless rounding is permitted in the description of the parameter. Rounding of parameter values, when permitted, shall be performed as follows: A target controller that receives a parameter value that is not an exact sup- ported value shall adjust the value to one that it supports and shall return CHECK CONDITION status with a sense key of RECOVERED ERROR. The additional sense code shall be set to ROUNDED PARAMETER. The initiating controller is responsible to issue an appropriate command to learn what value the target controller has selected. IMPLEMENTORS NOTE: Generally, the target should adjust maximum-value fields down to the next lower supported value than the one specified by the initiating controller. Minimum-value fields should be rounded up to the next higher supported value than the one specified by the initiating con- troller. In some cases, the type of rounding (up or down) is explicitly specified in the description of the parameter. 7.2.5 UNSUCCESSFUL I/O PROCESS TERMINATION CONDITION Upon detection of an unsuccessful I/O process termination condition, the target controller shall terminate the I/O process by clearing all pending data, establish a contintent allegiance, and prepare sense data that may be retrieved by a REQUEST SENSE command. (any AEN considerations? GRS) When an initiating controller detects an unexpected disconnect condition, it is recommended that a REQUEST SENSE command be attempted to obtain valid sense data that is available. 7-24 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7.2.6 RESET CONDITION (MANDATORY) The effect of the reset condition on I/O processes which have not completed, path groups, assignments, reservations, and SPP device operating modes is determined in the following section. SPP devices shall: (1) Attempt to complete any I/O processes which have not completed and that were fully identified (2) Preserve all SPP device path groups, path group status, assignments, passwords and reservations, as appropriate (3) Preserve any SPP device operating modes (MODE SELECT, PREVENT/ALLOW MEDIUM REMOVAL commands, etc.) (4) Preserve all the information required to continue normal dispatching of I/O processes queued prior to the reset condition. The SPP bus may be reset with minimum disruption to the operation of the logical system. To ensure proper operation the following conditions shall be met: (1) An initiator shall not consider an I/O process to be fully identified until it receive an acknowledgement information packet from the target. (2) A target shall consider an I/O process to be fully identified when the target detects no error in the information packet containing the identify information (3) If an initiator attempts a connection with a logical unit for which there already is an active I/O process with the same queue tag (if any) for the same initiator, the target shall clear the original I/O process and perform the new I/O process. (4) If a target attempts a reconnection with an initiator to continue an I/O process for which the initiator has no saved pointers, the initiator shall abort that unknown I/O process by sending the ABORT or ABORT I/O PROCESS message, depending on whether the I/O process is a tagged I/O process. The message is contained in an information packet. (5) An initiator shall consider an I/O process to be completed when no error is detected in the transfer of an information packet containing the I/O PROCESS COMPLETE message. (6) A target shall consider an I/O process to be completed when it detects the acknowledge information packet for the information packet containing the I/O PROCESS COMPLETE message. (7) When using information packets, an initiator shall not transmit an acknowledge information packet for an information packet until it has actu- ally saved the pointers for the current I/O process. Section 7. SPP I/O Process Control 7-25 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 (8) A target shall consider the pointers saved when it detects the acknowl- edgement packet for each information packet. (9) If the reset condition occurs before the acknowledgement information packet is received for an information packet containing a data interface logical element, the target shall terminate the I/O process with CHECK CON- DITION status. The target shall set the sense key to ABORTED COMMAND. This is necessary because the target cannot determine whether the data pointer has actually been saved. If the reset condition occurs during transfer of an information packet, the packet is retransmitted and the I/O process continues. 7.2.7 UNSUCCESSFUL INFORMATION PACKET TRANSFER CONDITION For an unsuccessful information packet transfer condition, the sending SCFI port: 1) may attempt to retransmit the information packet in error up to a limit determined by the sending SCFI port. 2) if operating in target mode for the I/O process, shall terminate the I/O process after the specified number of retries by clearing all pending data and preparing sense data. 3) if operating in initiator mode for the I/O process, shall abort the I/O process. The target controller prepares sense data. It is recommended that the initiator then request sense data from the target. 7.2.8 UNEXPECTED DISCONNECT CONDITION TBD 7.2.9 ATTENTION CONDITION (PARALLEL) TBD 7-26 SCSI-3 Packetized Protocol SCSI WORKING DOCUMENT X3T9.2/91-013 R01 END OF DOCUMENT X3T9.2/91-013 R01 X-1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +-------------------------------------------------------+ | TABLE DEFINITIONS | +-------------------------------------------------------+ ID FILE PAGE REFERENCES __ ____ ____ __________ B8R0CL S3R03CDD 1 5-3, 5-3, 5-3, 5-3, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 5-4, 6-1, 6-1, 6-1, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-2, 6-6, 6-7, 6-7, 6-7, 6-7 B7R1CL S3R03CDD 1 B6R2CL S3R03CDD 1 B61R2 S3R03CDD 1 B5R3CL S3R03CDD 1 B51R3 S3R03CDD 1 6-2 B55R3 S3R03CDD 1 B4R4CL S3R03CDD 1 B3R5CL S3R03CDD 1 5-3, 5-5 B31R5 S3R03CDD 1 B31R32 S3R03CDD 1 6-2 B2R6CL S3R03CDD 1 B2R6CL6 S3R03CDD 1 B2R4B11 S3R03CDD 1 5-8 B1R7CL S3R03CDD 1 B0R8CL S3R03CDD 1 5-3, 5-4, 5-4, 5-5, 5-8, 5-10, 6-1, 6-2, 6-6, 6-7 R1B6R1 S3R03CDD 1 5-10 R1B6S S3R03CDD 1 R2B4R2S S3R03CDD 1 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 R6B21 S3R03CDD 1 CMDHDR S3R03CDD 1 5-3, 5-4, 5-4, 5-5, 5-8, 5-10, 6-1, 6-2, 6-6, 6-6 ONECEL S3R03CDD 1 5-5, 7-4 CEL35 S3R03CDD 1 6-7, 6-7, 6-7, 6-7, 6-7, 6-7, 6-7, 6-7, 6-7, 7-1, 7-2, 7-2, 7-2, 7-2, 7-2, 7-2, 7-4, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5, 7-5 STHDR S3R03CDD 1 5-10, 5-11, 5-11 STBIT S3R03CDD 1 5-11, 5-11, 5-11, 5-11, 5-11, 5-11, 5-11, 5-11, 5-11, 5-11, 5-11 STONE S3R03CDD 1 5-11 COL15 S3R04A6D 7-2 7-2, 7-2, 7-2, 7-2, 7-2, 7-2, 7-2, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3, 7-3 MSGFMT S3R04A6D 7-4 7-4, 7-8, 7-10, 7-10, 7-12, 7-12, 7-14, 7-14, 7-17 MSG8BIT S3R04A6D 7-4 7-10, 7-12 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +-------------------------------------------------------+ | FIGURES | +-------------------------------------------------------+ ID FILE PAGE REFERENCES __ ____ ____ __________ S3P0110 S3R04A03 3-17 3-1 S3P0210 S3R04A03 3-18 3-2 S3P0310 S3R04A03 3-19 3-3 S3P0410 S3R04A03 3-20 3-4 S3P0610 S3R04A03 3-21 3-5 S3P0710 S3R04A03 3-22 3-6 S3P0810 S3R04A03 3-23 3-7 S6BUFR S3R04A6A 4-2 4-1 4-1 S6MNLOG S3R04A6A 4-10 4-2 4-1 S6SIMLS S3R04A6A 4-11 4-3 4-11 CONCIOP S3R04A6A 4-20 4-4 4-19 OPTYPE S3R04A6B 5-6 5-1 5-5 +-------------------------------------------------------+ | HEADINGS | +-------------------------------------------------------+ ID FILE PAGE REFERENCES __ ____ ____ __________ APPA ? ? ? 4-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 +-------------------------------------------------------+ | TABLES | +-------------------------------------------------------+ ID FILE PAGE REFERENCES __ ____ ____ __________ S6CMD06 S3R04A6B 5-3 5-1 5-3, 5-5 S6CMD10 S3R04A6B 5-4 5-2 5-3, 5-5, 5-5 S6CMD12 S3R04A6B 5-4 5-3 5-3, 5-5 S6OPCOD S3R04A6B 5-5 5-4 5-5 S6CTLFD S3R04A6B 5-8 5-5 5-8 S6STBYT S3R04A6B 5-10 5-6 5-9 S6STCOD S3R04A6B 5-11 5-7 5-11 S6IPSTR S3R04A6C 6-1 6-1 6-1 S6ICPFP S3R04A6C 6-2 6-2 6-2 S6ICPAD S3R04A6C 6-6 6-3 6-6 S6ILE S3R04A6C 6-7 6-4 6-6 S6ILEVL S3R04A6C 6-7 6-5 6-7 S6MSGTP S3R04A6D 7-2 7-1 7-1, 7-1 S6MSGCD S3R04A6D 7-2 7-2 7-1, 7-1, 7-1, 7-2, 7-6, 7-6 S6MSGFM S3R04A6D 7-4 7-3 7-2 S6EMSGC S3R04A6D 7-5 7-4 7-2, 7-4, 7-4, 7-4 S6EMJ S3R04A6D 7-8 7-5 SCSI WORKING DOCUMENT X3T9.2/91-013 R01 7-8 S6IBPD S3R04A6D 7-10 7-6 7-10 S6IIP S3R04A6D 7-11 7-7 7-10 S6MDP S3R04A6D 7-12 7-8 7-12 S6PE S3R04A6D 7-12 7-9 7-13 S6RPIP S3R04A6D 7-14 7-10 7-14 S6SDTR S3R04A6D 7-14 7-11 7-14 S6SPTR S3R04A6D 7-17 7-12 7-17 +-------------------------------------------------------+ | PROCESSING OPTIONS | +-------------------------------------------------------+ Runtime values: Document fileid ........................ S3R01013 SCRIPT Document type .......................... GDOC Document style ......................... IBMGGPL Profile ................................ EDFPRF30 Service Level .......................... 0013 SCRIPT/VS Release ...................... 3.2.1 Date ................................... 92.01.21 Time ................................... 11:54:59 Device ................................. 3270 Number of Passes ....................... 2 Index .................................. NO Formatting values used: Annotation ............................. NO Cross reference listing ................ YES Cross reference head prefix only ....... NO Dialog ................................. LABEL Duplex ................................. YES DVCF conditions file ................... (none) DVCF value 1 ........................... (none) DVCF value 2 ........................... (none) DVCF value 3 ........................... (none) DVCF value 4 ........................... (none) DVCF value 5 ........................... (none) DVCF value 6 ........................... (none) DVCF value 7 ........................... (none) SCSI WORKING DOCUMENT X3T9.2/91-013 R01 DVCF value 8 ........................... (none) DVCF value 9 ........................... (none) Explode ................................ NO Figure list on new page ................ YES Figure/table number separation ......... YES Folio-by-chapter ....................... YES Head 0 body text ....................... Part Head 1 body text ....................... Section Head 1 appendix text ................... Appendix Hyphenation ............................ YES Justification .......................... YES Language ............................... ENGL Layout ................................. 1 Leader dots ............................ YES Master index ........................... (none) Partial TOC (maximum level) ............ 4 Partial TOC (new page after) ........... RHPAGE Print example id's ..................... NO Print cross reference page numbers ..... YES Process value .......................... (none) Punctuation move characters ............ ., Read cross-reference file .............. (none) Running heading/footing rule ........... NONE Show index entries ..................... NO Table of Contents (maximum level) ...... 4 Table list on new page ................. YES Title page (draft) alignment ........... RIGHT Write cross-reference file ............. (none) +-------------------------------------------------------+ | Imbed Trace | +-------------------------------------------------------+ Page i S3R05A00 Page xii S3R03CDD Page 2 S3R04A01 Page 1-3 S3R04A02 Page 2-1 S3R04A03 Page 3-26 S3R04A6A Page 4-22 S3R04A6B Page 5-18 S3R04A6C Page 6-9 S3R04A6D