SCSI WORKING DOCUMENT X3T9.2/90-132 R00 August 30, 1990 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 Additions for Packetization/Serial Interface This document contains revisions to the SCSI-2 standard to incorporate function suitable for operation in a Fiber Channel environment. Extensions and corrections are presented with the text revised as required to make the new capabilities possible. This document has been combines X3T9.2/89-130 R01 and X3T9.2/89-133 R01 and replaces them. Terminology changes from the revision 1 documents are included from prior working group discussions. An extensive set of changes and additions has been made to the glossary in Section 3. Terminology is used consistently through all sections based on the new terms. Text has been added to Section 4 for the serial interface. An early description of the Fiber Channel options is included along with new messages to support needed functions. Sections 5 and 6 have been altered to define the boundary between the physical and logical layers between Sections 5 and 6. Section 5 deals strictly with the interface signal protocol, including the new nexus transfer phase. Corrections or replacements for SCSI-2 messages to improve function and clarify the role of initiator and target have been added to Section 6. Section 6 contains the logical operation model, pointer definition, the layout of information packets, the message system, commands (general definition and layout), status definition, and actions resulting from certain conditions. Certain events occurring in the physical layer are treated as conditions which exist or do not in the logical layer. This separates the definition of the condition from the action to be taken in the target controller as a result of the event occurring. An outline of new commands is given for Section 7. Gary R. Stephens 1 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 2 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 COVER PAGE Abstract: This standard defines mechanical, electrical, and functional requirements for attaching computers with each other as well as with intelligent peripherals such as rigid disks, flexible disks, magnetic tape devices, printers, optical disks, and scanners. The resulting interface facilitates the interconnection of computers and intelligent peripherals and thus provides a common interface specification for both systems integrators and suppliers of intelligent peripherals. Although originally targeted at small computer, there is no upper limit on the computer size to which this interface may connect. This document adds a new protocol to SCSI to encapsulate messages, commands, command parameter data, command response data, logical blocks, and status into information packets which are capable of being processed on both serial and parallel busses. SCSI-2 was limited to short parallel busses. This addition breaks a dependence on the transmission layers and length limitations of the SCSI-2 parallel bus. A multiple path management protocol is also added to permit greater availability and performance for computers using SCSI devices. The serial interface naturally lends itself to multiple path operation. This function is useful and adaptable to both the parallel and serial busses. 3 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 4 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 1. Scope This American National Standard defines input/output busses for interconnecting computers and peripheral devices. The standard defines extensions to the Small Computer System Interface (X3.131-198X), referred to herein as SCSI-2. It also provides new commands and messages and a more complete standardization of the previously defined command sets. The document includes the necessary specification of the mechanical, electrical, and functional characteristics of the interface to allow inter-operability of devices meeting the standard. Inter-operability is only assured between two SCSI devices having compatible physical transmission layer characteristics. This standard is referred to herein as SCSI-3. The term SCSI is used wherever it is not necessary to distinguish between SCSI-2 and SCSI-3. SCSI consists of a selection of I/O busses, logical commands, and responses that can be operated over a wide range of data rates. The various physical layers through SCSI-2, represented by connectors, cables, signal definitions, and the signal protocol, required a parallel cable system to operate successfully. In several instances in SCSI-2, byte-by-byte processing was mandatory. A new optional protocol permits all SCSI device transfers to occur at maximum rate, and eliminates the asynchronous nature of most portions of the SCSI-2 physical parallel interface. The primary objective of the interface is to provide computers with device type independence within a class of devices. Thus, different disk drives, tape drives, printers, optical media drives, and other devices can be added to the computers without requiring modifications to computer hardware or generic software capable of handling the mandatory functions for each device class. Provision is made for the addition of special features and functions through vendor specific fields and codes which may require computer software changes to use those features and functions. Reserved fields and code values are provided for future standardization. A second key objective of the standard is to provide compatibility with SCSI-2 devices. Properly conforming SCSI-2 devices, both initiators and targets, should respond in an acceptable manner to reject SCSI-3 protocol extensions. All SCSI-3 protocol extensions are designed to be permissive of such rejections and to allow SCSI-2 devices to continue inter-operation without requiring use of the extensions. SCSI-3 devices, both initiators and targets, attached to parallel busses, have the option of reverting to the SCSI-2 protocol to continue inter-operability with SCSI-2 devices. A third key objective of SCSI is to move device-dependent intelligence out to the devices. This requires the definition of a command set that allows an attached SCSI device to obtain all required initialization information from the other attached SCSI devices. The sequence of requests identify the class of attached SCSI device, the characteristics of the device, and all the changeable parameters supported by the device. Further requests can determine the readiness of the device to operate, the types of media supported by the device, and all other pertinent system information. Those parameters not required by the operating system for operation, initialization, or system tuning are not exposed to the interface, but are managed by the device itself. 5 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The new optional features of SCSI-3 permit transport layer independence, since certain signal protocol requirements have been removed and replaced by a logical interpretation of and response to information transfers. The optional features consist of new physical layer definitions for a serial protocol, and new commands, responses and messages. Operation in an environment with storage-to-storage transfers is possible without the use of a special I/O bus. Reserved information transfer phases in the SCSI-2 parallel physical protocol are defined to permit the new features to operate on parallel bus systems without conflicting with SCSI-2 operations. Length limitations, including arbitration delays, are still imposed on the parallel interfaces. For storage devices, the interface uses logical rather than physical addressing for all data blocks. For direct-access class devices, each logical unit may be interrogated to determine how many blocks it contains. A logical unit may coincide with all or part of a peripheral device or it may span multiple physical devices. The interface protocol includes provision for the connection of multiple initiators (SCSI devices capable of initiating an I/O process) and multiple targets (SCSI devices capable of responding to a request to perform an I/O process). A new optional provision provides for control of multiple initiator ports on one initiating controller and multiple target ports on one target controller using more than one I/O bus. In parallel bus implementations, 1) distributed arbitration (i.e., bus-contention logic) is built into the architecture of SCSI. 2) a priority system awards interface control to the highest priority SCSI device that is contending for use of the bus. 3) the time to complete arbitration is independent of the number of devices that are contending for the bus and arbitration can be completed in less than 10 microseconds. In serial bus implementations, 1) arbitration, if any, is a function of the serial protocol used and not defined in the SCSI architecture (e.g., a Fiber Channel serial layer). 2) the priority of access to the interface is a function of the serial protocol. 3) the time for arbitration, if any, is a function of the serial protocol used. Implementations which use other bus structures (e.g., a processor bus) for the transportation layer must follow the arbitration, priority and timing constraints of that implementation. The physical characteristics are described in Section 4. 6 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 In parallel bus implementations, there are two electrical alternatives: single-ended and differential. Single-ended and differential devices are electrically different and should not be mixed on the same bus. Provision is made for cable lengths up to 25 meters using differential drivers and receivers. A single-ended driver and receiver configuration is defined for cable lengths of up to 6 meters and is primarily intended for applications within a cabinet. In serial bus implementations, TBD, but current choices may include the Fiber Channel for up to 100 MB/S transfers in one direction. These new physical layers permit information transfers up to several kilometers. Section 5 describes the physical protocol for using the cables, connectors and signals for information transfer for both the parallel and serial interfaces. Logical level text has been moved to Section 6. Arbitration is unique to each physical layer to permit multiple initiators and to permit concurrent I/O processes. For parallel bus implementations, all SCSI devices are required to be capable of operating with the defined asynchronous transfer protocol. An optional synchronous transfer protocol is defined. An optional SCSI-3 information transfer protocol is defined in Section 5. The two message phases, the command phase, the status phase, and the two data phases are combined into two new information transfer phases. A logical operation model is introduced (See X3T9.2/89-133 R02) in Section 6. A packet structure is defined which encapsulates the logical information and data for transfer using the new information transfer phases. The logical functions transmitted by the SCSI-2 phases, encapsulated in information packets, is described. Section 6 specifies the message system protocol. New messages and protocols are introduced to support new functions and the new packet structure. The SCSI command and status structure is specified. Commands are classified as mandatory (M), optional (O), or vendor specific (V). SCSI devices are required to implement all mandatory commands defined for the appropriate device class and may implement other commands as well. Within each command, there are mandatory functions which must be implemented; there are optional functions within some commands which may be implemented. When a command is implemented, an SCSI device shall implement all functions identified as mandatory. SCSI devices contain commands that simplify the writing of self-configuring software drivers that can "discover" all necessary attributes without prior knowledge of specific peripheral characteristics (such as storage capacity). Many commands also implement a very large logical block address space (2**32 blocks), although some commands implement a somewhat smaller logical block address space (2**21 blocks). Section 7 specifies those commands that have a consistent meaning for all device classes. New commands for multiple path operation are defined in this section. 7 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Sections 8 through 17 contain commands for device classes called direct-access (e.g., magnetic disk), sequential-access (e.g., magnetic tape), printer, processor, write-once (e.g., optical disk), CD-ROM, scanner, optical memory, medium changer, and communications, respectively. The commands in each of these sections are unique to the device class, or they have interpretations, fields, or features that are specific for the device class. Thus, for example, although the WRITE command is used for several device classes, it has a somewhat different form for each class, with different parameters and meanings. Therefore, it is specified separately for each device class. Appendices are not a required part of this standard. They are included to give extra explanatory material about the interface options and the various protocols available. Appendices A through C provide examples of SCSI signal sequences, timing, and phase sequences for parallel bus implementations. (NOTE: These appendices need updating to include the nexus transfer phases introduced in Section 5.) Appendix D contains information on other standards related to medium types and density codes for flexible disks and magnetic tapes. Appendix E describes data integrity in command queuing environments. Appendix F describes normal procedures following a power-on condition. Appendix G describes the worst case skew times for a fast SCSI parallel bus implementation. Appendix H contains information on other SCSI standardization activities. Appendix I contains the additional sense codes and operation codes in numerical order. Appendix J contains the vendor identification codes as of the date of this document. 8 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 9 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 2. Referenced Standards and Organizations The requirements of ISO 8482:1987, "Information Processing - twisted pair multi-point interconnection data communication" apply to the use of differential drivers and receivers. American National Standard Small Computer System Interface, X3.131-1986, may also be useful to achieve compatibility with devices that conform to version 1 of SCSI. The medium catalog numbers in the CD-ROM section (13) are controlled by the Uniform Product Code Council, 8163 Old Yankee Road, Suite J, Dayton, Ohio 45459, U.S.A. and the European Article Number Council, Rue des Colonies, 54- BTE8, 1000 Brussels, Belgium. (NOTE: Add references to applicable serial interfaces as they become available. Also add CD-ROM standards references. GRS) 10 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 11 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 3. Glossary and Conventions 3.1. Glossary This section contains a glossary of special terms used in this standard. Also see glossaries in sections 6.1.1, 8.4, 9.4, ..., 17.4. active I/O process. For targets, an I/O process that is now in execution (not queued). For initiators, an I/O process for which a connect has been successfully performed. AEN. Asynchronous event notification (see Section 6). AWG. American Wire Gauge. burst. A contiguous set of bytes which represent all or part of the logical block(s) requested by a command, all or part of the command parameter data, or all or part of the command response data. Bursts are variable length. A burst transfer is made during a connection. A burst transfer is not part of every connection. Multiple burst transfers may occur in a single connection. byte. In this standard, this term indicates an 8-bit (octet) construct. CA. Contingent Allegiance (see Section 6). command. A command descriptor block, and optionally command parameter data, sent from an initiating controller to a target controller to cause a logical unit or target routine to perform some function for the initiating controller. command descriptor block (CDB). An organized collection of bytes used to communicate commands from an initiator to a target. This term is used to differentiate this data from messages, command parameter data, command response data, status and logical blocks. command parameter data. An organized collection of bytes (0 or more in length) provided as an addendum to command descriptor blocks of some commands. This term is used to differentiate this data from messages, CDBs, command response data, status and logical blocks. command response data. An organized collection of bytes (0 or more in length) provided in response to a command but which are not logical blocks from the target (e.g., sense data). This term is used to differentiate this data from messages, CDBs, command parameter data, status and logical blocks. command queue. A queue used to store the tagged I/O processes in both a initiating controller and a target controller (see Section 6). connect. The initiator function that selects a target and results in establishing a nexus and starting an I/O process. The connection that results is an initial connection. connection. An initial connection or reconnection. A connection can only occur between one initiator and one target. A connection begins at the end 12 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 of the SELECTION or RESELECTION phase; a connection ends with the next disconnect. contact. The electrically-conductive portion of a connector associated with a single conductor in a cable. current I/O process. The I/O process that is now connected on the SCSI bus. Only one I/O process may be current on a single SCSI bus. device class. A similar set of peripheral devices all having the same logical model as specified in Sections 8 through 17. Mandatory and optional functions are specified. device type. A specific peripheral device which implements some or all of the functions specified for its device class and some or all of those functions specified in Sections 5 through 7. All mandatory functions are implemented. disconnect. (Parallel interfaces.) The action that occurs when an SCSI device releases control of the SCSI bus, allowing it to go to the BUS FREE phase. (Serial interfaces.) The action that occurs when the end of an information packet transfer is reached. ECA. Extended Contingent Allegiance (see Section 6). field. A group of one or more contiguous bits. Fields containing only one bit are usually called the xx bit instead of the xx field. 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 I/O process. 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 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 nexus. H_C_x nexus. A nexus which is either an H_C_L or H_C_R nexus. H_C_L_Q nexus. A nexus between an initiating controller, a target controller, a logical unit, and a queue tag. This relationship replaces the prior H_C_L nexus. H_C_x_y nexus. A nexus which is either an H_C_x or H_C_L_Q nexus. H_I_T_C nexus. An H_C nexus, or one of its derivatives, between a host system and a target controller, restricted to one initiator and one target on one SCSI bus. An I_T nexus, or any of its derivatives, is an H_I_T_C nexus. ICID. initiating controller ID. 13 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 information packet. A group of bytes containing interface control fields and interface logical elements. initial connection. (Parallel interfaces.) An initial connection is the result of a connect. (Serial interfaces.) An initial connection is the result of a connect and the successful transfer of an information packet from the initiator. initiating controller. A logical element which principally starts I/O processes. I/O processes execute using the services of one or more ports in initiator mode. initiating controller ID. An initiating controller ID is an identifier for an initiating controller which is communicated to target controllers over an SCSI bus. initiator. An SCSI device, operating in initiator mode, through which an initiating controller starts I/O processes. An initiator usually attaches to an initiating controller. An initiator is a port to one SCSI bus. initiator mode. The current operating mode of an SCSI port which permits it to select another SCSI device port on the same SCSI bus. interface control fields. An organized collection of bytes used to encapsulate interface logical elements in information packets. Some of these fields are interpreted by the link layer for the proper routing of information packets between initiating controllers and target controllers. interface logical elements. Organized collections of bytes containing messages, CDBs, command parameter data, command response data, status, or logical blocks, or a self-describing combination of these. The self-describing version of the interface logical elements is used only with the nexus transfer phases. invalid. An illegal (reserved) or unsupported bit, field, code value, or bus phase. I/O process. An I/O process consists of one initial connection and zero or more reconnections, all related to the exchange of an ordered set of interface logical elements. The connection(s) pertain to a nexus where zero or more command descriptor blocks may be transferred. An I/O process begins with the establishment of a nexus. (Parallel interfaces.) An I/O process normally ends with the disconnect following successful transfer of a COMMAND COMPLETE or a RELEASE RECOVERY message. An I/O process also ends with the disconnect following an ABORT, ABORT TAG, BUS DEVICE RESET, or CLEAR QUEUE message or when a hard RESET condition or an unexpected disconnect occurs. (Serial interfaces.) An I/O process normally ends with the successful transfer of an information packet containing a COMMAND COMPLETE or a RELEASE RECOVERY message. An I/O process also ends with the successful transfer of an information packet containing an ABORT, ABORT TAG, BUS DEVICE RESET, or CLEAR QUEUE message or when a hard RESET condition has been successfully transmitted on the interface. 14 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 I_T nexus. An H_I_T_C nexus. A nexus, or any of its derivatives, which is restricted to one initiator and one target on one SCSI bus. I_T_L nexus. An I_T nexus which exists between one initiator, one target, and a logical unit. This relationship replaces the prior I_T nexus. I_T_R nexus. An I_T nexus which exists between one initiator, one target, and a target routine. This relationship replaces the prior I_T nexus. I_T_x nexus. An I_T nexus which is either an I_T_L or I_T_R nexus. I_T_L_Q nexus. An I_T nexus between one initiator, one target, a logical unit, and a queue tag following the successful receipt of one of the queue tag messages. This relationship replaces the prior I_T_L nexus. I_T_x_y nexus. An I_T nexus which is either an I_T_x or I_T_L_Q. identify function. A specific type of message used to identify the logical unit or target routine to be used during a nexus. logical block. A unit of data supplied from or requested by an initiator. This term is used to differentiate these data from messages, CDBs, command parameter data, command response data, and status. A logical block may be fixed or variable in length. logical unit. A physical or virtual peripheral device addressable through a target controller. logical unit number. An encoded identifier for a logical unit. LSB. Least significant bit. LUN. Logical unit number. message. An organized collection of bytes (1 or more) used for control of an SCSI bus between an initiator and a target or for control of a nexus, and such control is not possible through the defined commands. This term is used to differentiate these data from a CDB, command parameter data, command response data, status, and a logical block. mm. Millimeter. ms. Millisecond. MSB. Most significant bit. m**n. A mathematical expression representing the number m raised to the n-th power. Both m and n are integer decimal numbers. nexus. A relationship between an initiating controller and a target controller that begins with an initial connection and ends with the completion of the I/O process started during the initial connection. The relationship may be restricted to operate between one initiator and one target on a single SCSI bus. The relationship may be restricted to a single 15 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 logical unit or target routine through the identify function. The relationship may be further restricted by the queueing function. ns. Nanosecond. one. A true signal value or a true condition of a variable. page. Several commands use regular, self-describing parameter structures that are called pages. These pages are identified by a page code. Pages occur in command parameter data and command response data. 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 structure containing one or more fields. peripheral device. A physical device that can be attached to an SCSI device, and which, in turn, is attached to at least one SCSI bus through at least one SCSI port. A peripheral device and a SCSI device may be physically packaged together. Often there is a one-to-one mapping between peripheral devices and logical units, but this is not required. Examples of peripheral devices are: magnetic disks, printers, optical disks, magnetic tapes, and initiating controllers. Although not often thought of as peripheral devices, initiating controllers, which declare themselves as processor device types using target mode on at least one port in its SCSI device, are also peripheral devices. port. A port is the name for the portion of an SCSI device where it attaches to one SCSI bus. An SCSI device may have more than one port. Each port may attach to a different SCSI bus. Each port has an SCSI ID and an SCSI address unique to the SCSI bus to which it attaches. Ports function as initiators and/or targets. port number. When a port is in target mode, the port has a unique number within the target controller. queue tag. The value associated with an I/O process that uniquely identifies it from other queued I/O processes on the logical unit for the same initiating controller. queued I/O process. An I/O process that is in the command queue and is not an active I/O process. queueing function. A condition in both an initiating controller and a target controller when an I/O process is transferred for execution at a later time by the target controller. reconnect. The act of reviving a nexus to continue an I/O process. The connection may be on the same initiator and target pair as the last connection or on a different pair. The action taken by the target to revive the nexus depends on the initiating controller conditions established in the target controller. (Parallel interfaces.) A target controller reconnects with an initiator using the RESELECTION phase and transferring one or more messages. An initiator reconnects with a target using the SELECTION phase and causing the transfer of one or more messages. (Serial interfaces.) A 16 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 target reconnects by successfully transferring an information packet associated with a nexus to an appropriate initiator. An initiator reconnects by successfully transferring an information packet associated with a nexus to an appropriate target. reconnection. A reconnection is the result of a reconnect. (Parallel Interfaces.) A reconnection exists from the end of the SELECTION or RESELECTION phase until the next disconnect after a connect. (Serial Interfaces.) A reconnection exists while the receiving port is actively receiving an information packet after a connect. reserved. The term used for bits, fields, code values, and bus phases that are set aside for future standardization. SCSI. Either SCSI-2 or SCSI-3. SCSI-2. The Small Computer System Interface - 2 (X3.131-198X). SCSI-3. The Small Computer System Interface - 3 (X3.131-199X). SCSI address. The representation of the unique address assigned to one SCSI port on an SCSI device. This address would normally be assigned and set in each SCSI port during system installation. The SCSI address must be unique on a single SCSI bus. Two SCSI ports on the same SCSI device connected to the same SCSI bus must have different SCSI addresses. The form of the SCSI address varies with the physical interface used. SCSI ID. (Parallel interfaces.) The bit-significant representation of the SCSI address referring to one of the data bus signal lines available to the SCSI device excluding parity lines. (Serial interfaces.) The field value assigned to the source and destination fields of the interface control fields. Neither the SCSI ID nor the number of SCSI devices on a serial interface is related to the number of signal lines in the interface. SCSI device. A device configured for attachment to one or more SCSI busses via one or more SCSI ports. The device may allow an SCSI port to function either in initiator mode or in target mode for any one connection. Many SCSI devices implement only one mode for all SCSI ports. SCSI port. port. signal assertion. The act of driving a signal to the true state. (Parallel interfaces.) signal negation. The act of driving a signal to the false state or allowing the cable terminators to bias the signal to the false state (by placing the driver in the high impedance condition). (Parallel interfaces.) signal release. The act of allowing the cable terminators to bias the signal to the false state (by placing the driver in the high impedance condition). (Parallel interfaces.) status. One or more bytes of information sent from a target to an initiator at the completion of each command. This term is used to differentiate these 17 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 data from a message, a CDB, command parameter data, command response data, and a logical block. target. A port on an SCSI device which is principally responsible for receiving I/O processes. A target is usually attached to a target controller. A target is a port to one SCSI bus. target controller. A logical element which principally executes I/O processes for an initiating controller. target mode. The current operating mode of an SCSI port which permits it to be selected by another SCSI device port on the same SCSI bus. target routine. An addressable function within a target controller which executes I/O processes. A target routine is similar to a logical unit in that it 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 a target controller function to execute an I/O process. third-party. For COPY commands, third-party means a COPY command issued to one device to perform a copy operation between two other devices. For RESERVE or RELEASE commands, third- party means a reservation made for another device (e.g., A processor device requests that a direct-access device reserve itself for use by a sequential-access device). TRN. target routine number. unexpected disconnect. A disconnection that occurs because of a protocol error (see Section 5). (Parallel interfaces.) us. Microsecond. vendor specific (VS). Something (e.g., a bit, field, code value, etc.) that is identified in this standard, but whose use is not defined by this standard and may be used differently in various implementations. xx. Numbers, 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. Numbers immediately followed by lower-case "b" are binary values. xxh. Numbers immediately followed by lower-case "h" are hexadecimal values. zero. A false signal value or a false condition of a variable. 18 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 3.2. Editorial Conventions Certain words and terms used in this standard have a specific meaning beyond the normal English meaning. These words and terms are defined either in the glossary (see 3.1 and 6.1.1, 8.4, 9.4, ..., 17.4) or in the text where they first appear. Names of signals, phases, messages, commands, statuses, sense keys, additional sense codes, and additional sense code qualifiers are in all upper-case (e.g., REQUEST SENSE). Lower-case is used for words having the normal English definition unless the word or phrase is defined in context or in a glossary, then that definition is used. 3.3. Relationship of Some Defined Terms Some terms defined in the glossary have a relationship to one another which can be shown pictorially as follows. 19 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 SCSI DEVICE Configurations to Initiate an I/O Process -- SCSI Device as an Initiator --------------------------- | SCSI DEVICE | --------------------------------------- |INITIATING|| ||SCSI PORT | |CONTROLLER|| INITIATOR|| SCSI ADDRESS|-SCSI BUS- | || MODE || SCSI ID | --------------------------------------- -------------------------- | SCSI DEVICE | ------------------------------------------------- |PERIPHERAL|| TARGET || ||SCSI PORT | | DEVICE ||CONTROL- ||INITIATOR|| SCSI ADDRESS|-SCSI BUS- | || LER || MODE || SCSI ID | ------------------------------------------------- Configurations to Execute an I/O Process -- SCSI Device as a Target ----------------------- | SCSI DEVICE | ------------------------------------------------------ |PERIPHERAL||LU+LUN || TARGET || ||SCSI PORT | | DEVICE ||-------||CONTROL-||TARGET|| SCSI ADDRESS|-SCSI BUS- |----------||TARGET || LER || MODE || SCSI ID | |PERIPHERAL||ROUTINE|| || || | | DEVICE ||----------------------------------------- ------------- ------------------------- | SCSI DEVICE | ---------------------------------------------- | ||LU+LUN || ||SCSI PORT | |INITIATING||-------|| TARGET || SCSI ADDRESS|-SCSI BUS- |CONTROLLER||TARGET || MODE || SCSI ID | | ||ROUTINE|| || | ---------------------------------------------- 20 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 LOGICAL ACTIVITY CONSTRUCTS ------------------------- NEXUS ------------------------- ---------------------- I/O PROCESS ---------------------- ------------------ ACTIVE I/O PROCESS ------------------- CURRENT I/O PROCESS CURRENT I/O PROCESS ___I/O BUS ACTIVE___ ____________________ ___| |_I/O BUS INACTIVE_| |___ INFORMATION PACKET INFORMATION PACKET CONNECTION DISCONNECT CONNECTION DISCONNECT CONNECT INITIAL CONNECTION RECONNECTION INFORMATION PACKET CONTENT INTERFACE CONTROL FIELDS INTERFACE LOGICAL ELEMENTS message(s) command descriptor block command parameter data command response data logical block(s) status INFORMATION PACKET TRANSFER MANAGEMENT SCSI-2 SCSI-3 (w/Option) special phases and interface general phases and logical elements self-describing interface logical elements 21 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 COMPARISON OF BUS ACTIVITIES CONNECTION 1 CONNECTION 1 (Connect) (Connect) MESSAGE OUT phase (w/Attention) INFORMATION TRANSFER OUT phase message(s) message(s) COMMAND phase command descriptor command descriptor block command parameter data (Opt.) DATA OUT phase (Opt.) command parameter data (Opt.) MESSAGE IN phase message(s) CONNECTION 2 CONNECTION 2 (reconnect) (reconnect) MESSAGE IN phase INFORMATION TRANSFER IN phase message(s) message(s) DATA IN/OUT phase(s) logical block(s) logical block burst(s) or command response data or command response data status STATUS phase message(s) status MESSAGE IN phase message(s) The SCSI-3 optional mode is required to operate on a serial interface. For the serial interface there are only three phases: BUS FREE, INFORMATION TRANSFER IN, INFORMATION TRANSFER OUT. 22 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 23 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 4. Physical Characteristics This section contains the definition of the physical transport layers of SCSI. Sections 4.1 through 4.8 describe the parallel physical transport layer options available. Sections 4.9 through 4.16 describe the serial physical transport layer options available. The connectors, cables, signals, terminators, and bus timing values needed to implement each transport layer are specified. For the serial interface, references are made to the appropriate standards and the options from those standards applicable to SCSI-3 are specified. See Section 2 for the complete titles and document numbers for these standards. 4.1. Parallel Interface Physical Description (Replace with P-Cable text.) 4.2. Parallel Interface Cable Requirements (Replace with P-Cable text.) 4.3. Parallel Interface Connector Requirements (Replace with P-Cable text.) 4.4. Parallel Interface Electrical Description (Replace with P-Cable text.) 4.5. Parallel Interface SCSI Bus (Replace with P-Cable text.) 4.6. Parallel Interface SCSI Bus Signals (Replace with P-Cable text.) 4.7. Parallel Interface SCSI Bus Timing (Replace with P-Cable text.) 4.8. Parallel Interface Fast Synchronous Transfer Option (Replace with P-Cable text.) 4.9. Serial Interface Physical Description SCSI devices attached to a serial interface use a 2-conductor cable made up from either copper wire or optical fiber strands. One conductor always transfers information packets into the SCSI device, called the receive conductor, and one conductor always transfers information packets away from the SCSI device, called the send conductor. Within the optical fiber option, 24 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 there are plastic and glass conductors. Inter-operability of implementations using different types of conductors is not to be assumed from this standard. There are two layouts or topologies defined. The topologies are called point-to-point and string. The topology selected for an implementation determines the type of SCSI port required in an SCSI device. Inter-operability of implementations using different topologies is not to be presumed from this standard. Refer to the appropriate standard. All transfers use a synchronous mode of transfer. The method for balancing the count of bytes transferred during a connection is different from for parallel interfaces. For each information packet received on the receive conductor and not forwarded, there is an acknowledgement information packet sent on the send conductor. Since one or more information packets may be in the conductors at the same time, there is no mechanism to acknowledge receipt of bytes on a byte-by-byte basis. The six mutually exclusive choices are identified in Table 4-qq. NOTE: Appropriate adapters might be constructed, whose functions are outside the scope of this standard, which would permit inter-operability. Table 4-qq. Serial Transport Layer Options CONDUCTOR TYPE TOPOLOGY Copper Optical String Switch Plastic Glass Required Point-to-Point x x x No String x x x Yes 4.9.1. Point-to-Point Topology A point-to-point topology exists when, from the initiator and target perspective, one conductor is outbound from the initiator and the other is inbound to the initiator, respectively. No other devices appear to share the conductors. The send conductor of the initiator is connected to the receive conductor of the target and the send conductor of the target is connected to the receive conductor of the initiator. See Figure 4.ww. Figure 4.ww shows one implementation of the point-to-point topology which provides one initiator for each target and a single 2-conductor cable attached between them. Although possible, this is not a likely implementation, except for high performance devices or for some other system integration reason. In this implementation, every information packet received by an SCSI device has only one source. Every information packet sent has only one destination. 25 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Figure 4-ww. Example of Point-to-Point Topology ----------- -------- | |--------Outbound Information ----------->| | |INITIATOR| |TARGET| | |<--------Inbound Information ------------| | ----------- -------- The most likely implementation of a point-to-point topology consists of one or more point-to-point switches between the initiator and the target. The switches are specified as part of the applicable standards. The initiators and targets are attached to a switch. The switches may be interconnected to provide addressability to a large set of SCSI devices. Conditions in the point-to-point switches are established in such a way to make a connection appear point-to-point (See Figure 4.ww above). Multiple initiators and targets may be attached to the switches and then the paths through the switches are adjusted, as required, to provide physical paths between an initiator and a target for the duration of a connection. The mechanism for adjusting the switches is part of the applicable standards. In the example in Figure 4.xx, information packets may be transferred on both of the send conductors to a target controller while, at the same time, receiving information packets on both receive conductors from the same target controller. The number of available ports, the use of multiple path operation, and the complexity of the switches determines the number of concurrent connections possible. The maximum in this example is six concurrent connections. The cabling between switches does not add to the level of concurrent connections. 26 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Figure 4-xx. Example of Point-to-Point Topology with Switches Other Switches or SCSI Ports | | ----------------- | | --------------- | | | | | | | H ----------- -------- -------- T | | O | |--Send--->| |-Receive->| | A | | S |INITIATOR| |SWITCH| |TARGET| R | | T | |<-Receive-| |<--Send---| | G C | | ----------- -------- -------- E O | | S | | | | T N | | Y | | | | T | | S ----------- -------- -------- R | | T | |--Send--->| |-Receive->| | O | | E |INITIATOR| |SWITCH| |TARGET| L | | M | |<-Receive-| |<--Send---| | L | | ----------- -------- -------- E | | | | | | R | ----------------- | | --------------- | | Other Switches or SCSI Ports In Figure 4.xx, every information packet received by an SCSI port is similar to parallel daisy-chained implementations. That is, the switch settings provide the same isolation of SCSI ports during a connection as does the SELECTION or RESELECTION phase on a parallel interface. Concurrency in parallel bus operation is limited by the number of SCSI busses. In Figure 4.xx, each information packet may be sent to a different destination, and each information packet received may come from a different source. This is similar to parallel bus operation where each arbitration phase may result in connections between various initiators and targets connected to an SCSI bus. 4.9.2. String Topology String topology looks similar to the parallel daisy-chained bus implementation, but it is not. String topology places one additional requirement on each SCSI port, has one performance implication, and has one availability implication. The string topology forms a loop from the send conductor of an SCSI device port to its receive conductor. See Figure 4.zz. The conductor passes through a four-point single-conductor string switch for each attached SCSI port. See Figure 4.yy. 27 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Figure 4.zz. Example of String Topology and Point-to_Point Topology Other Switches or SCSI Devices | | | | | | <----- STRING ------> ----------- -------- -------- -------- | |---Send-->| |-Receive->|TARGET|---->|TARGET|----| |INITIATOR| |SWITCH| -------- -------- | | |<-Receive-| |<--Send----------------------------- ----------- -------- | | | | | | Other Switches or SCSI Devices The effective bandwidth of the string topology is one-half the point-to-point topology. There are one-half as many conductors as in the point-to-point topology. The string becomes inoperative when any string switch or connecting cable becomes inoperative. That is, information packet forwarding fails when a string switch fails or a cable is disconnected or breaks. The receive conductor of the string switch in Figure 4.yy is switched to either receive conductor of the local SCSI port or it is switched to the send conductor of the string switch and forwarded to the next SCSI port attached to the string. The local SCSI port has its send conductor attached to the switch, and the switch always routes an information packet on the send conductor of the string switch. Each conductor on this switch has a mandatory flow directions and decision points as specified above and shown in Figure 4.yy. NOTE: The SCSI port may be implemented as a point-to-point connection to the local SCSI device conductors of the string switch. This potentially permits one implementation of the SCSI port to be used in either topology. This permits the string switch to be a separate component in the configuration. If the string switch were not an expensive element and could be packaged with and initialized by the SCSI device, the string switch could be made transparent in point-to-point mode and active in string mode. If the string switch has a bypass mode, the SCSI port can be added to or taken away from the string without disrupting string operation (i.e., hot plugged). 28 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Figure 4.yy. Example of SCSI Port with String Switch RECEIVE SEND -------------- -------------> CONDUCTOR | | CONDUCTOR V | --|---------|-- | S-------->S | | | A | | | STRING | | | | SWITCH | | | | | | --|---------|-- LOCAL | | LOCAL OUTBOUND | | INBOUND V | ----------------------------------- | | SCSI | | | | DEVICE | | | | PORT | | | --------------- | | | | SCSI Device | | | ----------------------------------- V, A, and > show the direction of the flow of information packets. S shows the switch points where direction decisions must be made and implemented. The information packet from a sender is transferred on its send conductor and then each string switch on the string, in turn, receives each information packet on its receive conductor and checks to see if it is addressed to the local SCSI port. If it is not addressed to that SCSI port, the information packet is switched to the send conductor of the string switch. If the information packet is improperly addressed, it will be forwarded back to the sender and received on the original sender's receive conductor. Since the sender also has a string switch port, available bandwidth may be reduced if the information packet continues to cycle in the loop. If the packet is correctly addressed to the local SCSI port, then the string switch will route the information packet to the receive conductor of the SCSI port. The SCSI port will then send an acknowledgement information packet on its send conductor. The acknowledgement information packet is addressed to the sender of the original information packet. The string switch always routes this information packet on its send conductor. In the string topology, string switches may be separated by zero or more point-to-point switches. See Figure 4.zz. The connection through these switches is always 2-conductors, point-to-point. That is, the two conductors 29 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 into the switch for a string are always routed through the switch in pairs, unlike the string switch which routes only one conductor. A single conductor of a string shall not be routed through a point-to-point switch. A target on the string in Figure 4.zz sends an information packet on its send conductor. The information packet is received, checked, and forwarded by each string switch until it is received at its destination. The SCSI port, represented as an initiator in Figure 4.zz, must be attached to a string switch since it must be capable of forwarding information packets sent between any two SCSI ports on the string (i.e., normal SCSI peer-to-peer operation on a single bus). 4.10. Serial Interface Cable Requirements TBD 4.10.1. Copper 4.10.2 Optical Glass 4.10.3 Optical Plastic 4.11. Serial Interface Connector Requirements TBD 4.11.1. Copper 4.11.2 Optical Glass 4.11.3 Optical Plastic 4.12. Serial Interface Electrical Description for Copper TBD 4.13. Serial Interface Optical Description 4.13.1 Optical Glass 4.13.2 Optical Plastic 4.14. Serial Interface Bus TBD 30 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 4.15. Serial Interface Signals TBD 4.15.1. Electrical 4.15.2. Optical Glass 4.15.2. Optical Plastic 4.16. Serial Interface Timing TBD 4.16.1. Electrical 4.16.2 Optical Glass 4.16.3 Optical Plastic 31 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 32 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 5. Protocol for Information Transfer The protocol for information transfer for busses specified in Section 4 is divided into two parts: 1) parallel interface in Sections 5.1 through 5.3; 2) serial interface in Sections 5.4 through 5.6; The information transfer phases defined in SCSI-2 are still defined and work as before. The interface logical elements are not formed in to self describing units, but rather the SCSI-2 information transfer phases serve as descriptors. The variable length nature of interface logical elements is generally variable to the initiator for inbound transfers and some outbound data transfers. The target has only one variable interface logical element and that is outbound messages. The optional nexus transfer phase provides an alternative protocol for the way information is transferred across the SCSI bus. Interface logical elements are formed in to self describing units and are then placed into an information packet of variable length. The information packet is then transferred using the nexus transfer phase. The nexus transfer phase requires that all interface logical element lengths be declared in an information packet in advance of the information packet transfer on the SCSI bus. With the information packet structure, it is possible to perform all operations using only the nexus transfer phase. No interpretation of the data in the information packet shall be permitted which halts the transfer of the information packet on the interface. Parity errors are handled by retransmitting the information packet. The initial information packet transfers on the parallel SCSI bus, which are in asynchronous data transfer mode, shall have no interlock mechanism on the individual bytes as they are transferred. Only the actual transfer time may be slower than in synchronous data transfer mode. For serial interface implementations, all transfers are in synchronous data transfer mode, and the nexus transfer phase is the only phase available for information transfer. 5.1. Parallel Interface SCSI Bus Phases The SCSI architecture includes nine distinct phases: BUS FREE phase ARBITRATION phase SELECTION phase RESELECTION phase COMMAND phase \ DATA phase \ These phases are collectively termed the STATUS phase / information transfer phases. 33 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 MESSAGE phase / NEXUS TRANSFER phase / The SCSI bus can never be in more than one phase at any given time. In the following descriptions, signals that are not mentioned shall not be asserted. The nexus transfer phase is mutually exclusive of the other information transfer phases for an I/O process. During a connect, if the first information transfer phase of a connection is not a nexus transfer phase, then it shall be an error to attempt to use a nexus transfer phase within the same connection or any subsequent connection for the I/O process. Conversely, if the first information transfer phase of a connect is a nexus transfer phase, it shall be an error to attempt to use any other phase within the same connection or a subsequent connection for the I/O process. Since targets control the selection of information transfer phases, the target must initiate a procedure, at power-on or after the reset condition, which declares that it is capable of operating with the nexus transfer phase. The first information packet transferred on a parallel interface, after power-on reset or after processing the reset condition by a target, shall contain a request to negotiate synchronous data transfer using the nexus transfer phase. Wide data transfer is negotiated separately. The initiator has one of three courses of action: 1) If it does not implement target mode, it will not respond to selection, and the target discovers that it may only operate in SCSI-2 mode with the initiator. 2) If it implements target mode and the nexus transfer phase, the initiator accepts the information packet and by so doing declares itself capable of handling the nexus transfer phases. 3) If it is an initiator which does not implement the nexus transfer phase, it shall signal ATN on the first assertion of REQ for the illegal phase and shall not assert the ACK signal. If ATN is asserted, the target controller disconnects allowing the bus to go to the BUS FREE phase. With the change to the BUS FREE phase, the initiator shall release its ATN signal. The target has detected that it is possible to operate with that initiator using only the SCSI-2 defined information transfer phases and shall not attempt to use the nexus transfer phases with that initiator until after a power-on reset, or a reset condition has been processed. The initiator detects an unexpected disconnect and reacts appropriately. See Sections 5.1.1 and 5.2.1. 5.1.1. BUS FREE Phase The BUS FREE phase is used to indicate that no SCSI device is actively using the SCSI bus and that it is available. In some cases a target reverts to BUS FREE phase to indicate an error condition that it has no other way to handle. This is called as an unexpected disconnect. SCSI devices shall detect the BUS FREE phase after the SEL and BSY signals are both false for at least a bus settle delay. 34 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 SCSI devices shall release all SCSI bus signals within a bus clear delay after the BSY and SEL signals become continuously false for a bus settle delay. If an SCSI device requires more than a bus settle delay to detect the BUS FREE phase then it shall release all SCSI bus signals within a bus clear delay minus the excess time to detect the BUS FREE phase. The total time to clear the SCSI bus shall not exceed a bus settle delay plus a bus clear delay. Initiators normally do not expect BUS FREE phase to begin, because the target releases the BSY signal, except after one of the following occurrences: (1) after a reset condition is detected. (2) after an ABORT message is successfully received by a target. (3) after a BUS DEVICE RESET message is successfully received by a target. (4) after a DISCONNECT message is successfully transmitted from a target. (5) after a COMMAND COMPLETE message is successfully transmitted from a target. (6) after a RELEASE RECOVERY message is successfully received by a target. (7) after an ABORT TAG message is successfully received by a target. (8) after a CLEAR QUEUE message is successfully received by a target. (9) after the transfer of an information packet in the nexus transfer phase. (10) after failure of a target to transfer an information packet using the NEXUS TRANSFER IN phase. The BUS FREE phase may also be entered after an unsuccessful selection or reselection, although in this case it is the release of the SEL signal rather than the release of the BSY signal that first establishes the BUS FREE phase. This is not treated as an unexpected disconnect. All other occurrences of a BUS FREE state cause the initiator to establish an Unexpected BUS FREE Condition for the Initiating Controller. (See Section 6.) 5.1.2. ARBITRATION Phase The ARBITRATION phase allows one SCSI device to gain control of the SCSI bus so that it can initiate or resume an I/O process. The procedure for an SCSI device to obtain control of the SCSI bus is as follows: (1) The SCSI device shall first wait for the BUS FREE phase to occur. The BUS FREE phase is detected whenever both the BSY and SEL signals are simultaneously and continuously false for a minimum of a bus settle delay. 35 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 IMPLEMENTORS NOTE: This bus settle delay is necessary because a transmission line phenomenon known as a "wired-OR glitch" may cause the BSY signal to briefly appear false, even though it is being driven true. (2) The SCSI device shall wait a minimum of a bus free delay after detection of the BUS FREE phase (i.e. after the BSY and SEL signals are both false for a bus settle delay) before driving any signal. (3) Following the bus free delay in Step (2), the SCSI device may arbitrate for the SCSI bus by asserting both the BSY signal and its own SCSI ID, however the SCSI device shall not arbitrate (i.e. assert the BSY signal and its SCSI ID) if more than a bus set delay has passed since the BUS FREE phase was last observed. IMPLEMENTORS NOTE: There is no maximum delay before asserting the BSY signal and the SCSI ID following the bus free delay in Step (2) as long as the bus remains in the BUS FREE phase. However, SCSI devices that delay longer than a bus settle delay plus a bus set delay from the time when the BSY and SEL signals first become false may fail to participate in arbitration when competing with faster SCSI devices. (4) After waiting at least an arbitration delay (measured from its assertion of the BSY signal) the SCSI device shall examine the DATA BUS. If a higher priority SCSI ID bit is true on the DATA BUS (DB(7) is the highest), then the SCSI device has lost the arbitration and the SCSI device may release its signals and return to Step (1). If no higher priority SCSI ID bit is true on the DATA BUS, then the SCSI device has won the arbitration and it shall assert the SEL signal. Any SCSI device other than the winner has lost the arbitration and shall release the BSY signal and its SCSI ID bit within a bus clear delay after the SEL signal becomes true. An SCSI device that loses arbitration may return to Step (1). IMPLEMENTORS NOTE: It is recommended that new implementations wait for the SEL signal to become true before releasing the BSY signal and SCSI ID bit when arbitration is lost. (5) The SCSI device that wins arbitration shall wait at least a bus clear delay plus a bus settle delay after asserting the SEL signal before changing any signals. NOTE: The SCSI ID bit is a single bit on the DATA BUS that corresponds to the SCSI device's unique SCSI address. All other DATA BUS bits shall be released by the SCSI device. Parity is not valid during the ARBITRATION phase. During the ARBITRATION phase, the data bus parity bits may be released or asserted, but shall not be actively driven false. 5.1.3. SELECTION Phase The SELECTION phase allows an initiator to select a target for the purpose of initiating some target function (e.g., READ or WRITE command). The SELECTION phase may also be used by an initiator to reconnect with a target after a disconnect. During the SELECTION phase the I/O signal is negated so that this phase can be distinguished from the RESELECTION phase. 36 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The SCSI device that won arbitration has both the BSY and SEL signals asserted and has delayed at least a bus clear delay plus a bus settle delay before ending the ARBITRATION phase. The SCSI device that won the arbitration becomes an initiator by not asserting the I/O signal. The initiator shall set the DATA BUS to a value which is the OR of its SCSI ID bit and the target's SCSI ID bit and it shall assert the ATN signal (indicating that a MESSAGE OUT phase is to follow the SELECTION phase). The initiator shall then wait at least two deskew delays and release the BSY signal. The initiator shall then wait at least a bus settle delay before looking for a response from the target. The target shall determine that it is selected when the SEL signal and its SCSI ID bit are true and the BSY and I/O signals are false for at least a bus settle delay. The selected target may examine the DATA BUS in order to determine the SCSI ID of the selecting initiator. The selected target shall then assert the BSY signal within a selection abort time of its most recent detection of being selected; this is required for correct operation of the selection time-out procedure. The target shall not respond to a selection if bad parity is detected. Also, if more than two SCSI ID bits are on the DATA BUS, the target shall not respond to selection. IMPLEMENTORS NOTE: If a target chooses to support the single initiator option of SCSI-1, it should not be an error to have only the target ID bit present during selection. In this case the target may respond as an SCSI-1 device. No less than two deskew delays after the initiator detects the BSY signal is true, it shall release the SEL signal and may change the DATA BUS. The target shall wait until the SEL signal is false before asserting the REQ signal to enter an information transfer phase. 5.1.3.1. SELECTION Time-out Procedure The following selection time-out procedures is specified for clearing the SCSI bus if the initiator waits a minimum of a selection time-out delay and there has been no BSY signal response from the target. The initiator shall continue asserting the SEL and ATN signals and shall release the DATA BUS. If the initiator has not detected the BSY signal to be true after at least a selection abort time plus two deskew delays, the initiator shall release the SEL and ATN signals allowing the SCSI bus to go to the BUS FREE phase. SCSI devices shall ensure that when responding to selection that the selection was still valid within a selection abort time of their assertion of the BSY signal. Failure to comply with this requirement could result in an improper selection (two targets connected to the same initiator, wrong target connected to an initiator, or a target connected to no initiator). 5.1.4. RESELECTION Phase 37 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 RESELECTION is an optional phase that allows a target to reconnect to an initiator for the purpose of continuing some operation that was previously started by the initiator but was suspended by the target, (i.e., the target disconnected by allowing a BUS FREE phase to occur before the operation was complete). The RESELECTION phase is required to be supported in both the initiator and the target when the NEXUS TRANSFER phase is implemented. 5.1.4.1. RESELECTION Upon completing the ARBITRATION phase, the winning SCSI device has both the BSY and SEL signals asserted and has delayed at least a bus clear delay plus a bus settle delay. The winning SCSI device becomes a target by asserting the I/O signal. The winning SCSI device shall also set the DATA BUS to a value that is the logical OR of its SCSI ID bit and the initiator's SCSI ID bit. The target shall wait at least two deskew delays and release the BSY signal. The target shall then wait at least a bus settle delay before looking for a response from the initiator. The initiator shall determine that it is reselected when the SEL and I/O signals and its SCSI ID bit are true and the BSY signal is false for at least a bus settle delay. The reselected initiator may examine the DATA BUS in order to determine the SCSI ID of the target. The reselected initiator shall then assert the BSY signal within a selection abort time of its most recent detection of being reselected; this is required for correct operation of the time-out procedure. The initiator shall not respond to a RESELECTION phase if bad parity is detected. Also, the initiator shall not respond to a RESELECTION phase if other than two SCSI ID bits are on the DATA BUS. After the target detects the BSY signal is true, it shall also assert the BSY signal and wait at least two deskew delays and then release the SEL signal. The target may then change the I/O signal and the DATA BUS. After the reselected initiator detects the SEL signal is false, it shall release the BSY signal. The target shall continue asserting the BSY signal until it relinquishes the SCSI bus. NOTE: When the target is asserting the BSY signal, a transmission line phenomenon known as a "wired-OR glitch" may cause the BSY signal to appear false for up to a round-trip propagation delay following the release of the BSY signal by the initiator. This is the reason why the BUS FREE phase is recognized only after both the BSY and SEL signals are continuously false for a minimum of a bus settle delay. Cables longer than 25 meters should not be used even if the chosen driver, receiver, and cable provide adequate noise margins, because they increase the duration of the glitch and could cause SCSI devices to inadvertently detect the BUS FREE phase. 5.1.4.2. RESELECTION Time-out Procedure The following RESELECTION time-out procedure is specified for clearing the SCSI bus during a RESELECTION phase if the target waits a minimum of a selection time-out delay and there has been no BSY signal response from the initiator. 38 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The target shall continue asserting the SEL and I/O signals and shall release all DATA BUS signals. If the target has not detected the BSY signal to be true after at least a selection abort time plus two deskew delays, the target shall release the SEL and I/O signals allowing the SCSI bus to go to the BUS FREE phase. SCSI devices that respond to the RESELECTION phase shall ensure that the reselection was still valid within a selection abort time of their assertion of the BSY signal. Failure to comply with this requirement could result in an improper reselection (two initiators connected to the same target or the wrong initiator connected to a target). 5.1.5. Information Transfer Phases The COMMAND, DATA, STATUS, MESSAGE, and NEXUS TRANSFER phases are all grouped together as the information transfer phases because they are all used to transfer data or control information via the DATA BUS. The actual content of the information is beyond the scope of this section (See Section 6.). In SCSI-2, the MESSAGE, COMMAND, data phases, and STATUS phase are used to identify the type of data being transferred during a connection. The optional nexus transfer phases may be used for all transfers. The C/D, I/O, and MSG signals are used to distinguish between the different information transfer phases (see Table 5-1). The target drives these three signals and therefore controls all changes from one phase to another. The initiator can request either a MESSAGE OUT phase or a NEXUS TRANSFER OUT phase by asserting the ATN signal, while the target can cause the BUS FREE phase by releasing the MSG, C/D, I/O, and BSY signals. The information transfer phases use one or more REQ/ACK handshakes to control the information transfer. Each REQ/ACK handshake allows the transfer of one byte of information on the A cable and up to 3 bytes of information on the B cable, or up to 2 bytes of information on the P cable. The data capable of being transferred on one handshake is further limited by the phase in which the transfer is attempted. During the information transfer phases the BSY signal shall remain true and the SEL signal shall remain false. Additionally, during the information transfer phases, the target shall continuously envelope the REQ/ACK handshake(s) with the C/D, I/O, and MSG signals in such a manner that these control signals are valid for a bus settle delay before the assertion of the REQ signal of the first handshake and remain valid until after the negation of the ACK signal at the end of the handshake of the last transfer of the phase. An information transfer phase is defined as ending when the C/D, I/O, or MSG signals change after the negation of the ACK signal. The time between the end of a phase and the assertion of the REQ signal beginning a new phase is undefined. After the negation of the ACK signal of the last transfer of an information transfer phase, the target may prepare for a new phase by asserting or negating the C/D, I/O, and MSG signals. These signals may be changed together or individually. They may be changed in any order and may be changed more than once. It is desirable that each line change only once. A 39 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 new phase does not begin until the REQ signal is asserted for the first byte of the new phase. An initiator is allowed to anticipate a new phase based on the previous phase, the expected new phase, and early information provided by changes in the C/D, I/O, and MSG signals. However, the actual phase is not valid until the REQ signal is asserted at the beginning of the next phase. Two or more phases of the same type may be processed back-to-back provided that there is a pause between the data bytes with both REQ and ACK false and the C/D, I/O, and MSG signals are changed and then set to the same phase as the previous phase. Table 5-1: Information Transfer Phases ============================================================================== Signal ----------- MSG C/D I/O Phase Name Direction Of Transfer Comment ------------------------------------------------------------------------------ 0 0 0 DATA OUT Initiator to target \ Data 0 0 1 DATA IN Initiator from target / Phase 0 1 0 COMMAND Initiator to target 0 1 1 STATUS Initiator from target 1 0 0 * NEXUS TRANSFER OUT Initiator to target \ Nexus 1 0 1 * NEXUS TRANSFER IN Initiator from target / Transfer Phase 1 1 0 MESSAGE OUT Initiator to target Message 1 1 1 MESSAGE IN Initiator from target Phase ============================================================================== Key: 0 = False, 1 = True, * = Optional. 5.1.5.1. Asynchronous Information Transfer The target shall control the direction of information transfer by means of the I/O signal. When the I/O signal is true, information shall be transferred from the target to the initiator. When the I/O signal is false, information shall be transferred from the initiator to the target. If the I/O signal is true (transfer to the initiator), the target shall first drive the DB(7-0,P) signals to their desired values, delay at least one deskew delay plus a cable skew delay, then assert the REQ signal. The DB(7- 0,P) signals shall remain valid until the ACK signal is true at the target. The initiator shall read the DB(7-0,P) signals after the REQ signal is true, then indicate its acceptance of the data by asserting the ACK signal. When the ACK signal becomes true at the target, the target may change or release the DB(7-0,P) signals and shall negate the REQ signal. After the REQ signal is false the initiator shall then negate the ACK signal. After the ACK signal is false the target may continue the transfer by driving the DB(7-0,P) signals and asserting the REQ signal, as described above. 40 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 If the I/O signal is false (transfer to the target) the target shall request information by asserting the REQ signal. The initiator shall drive the DB(7- 0,P) signals to their desired values, delay at least one deskew delay plus a cable skew delay and assert the ACK signal. The initiator shall continue to drive the DB(7-0,P) signals until the REQ signal is false. When the ACK signal becomes true at the target, the target shall read the DB(7-0,P), signals then negate the REQ signal. When the REQ signal becomes false at the initiator, the initiator may change or release the DB(7-0,P) signals and shall negate the ACK signal. The target may continue the transfer by asserting the REQ signal, as described above. 5.1.5.2. Synchronous Data Transfer Synchronous data transfer is optional and is only used in data and nexus transfer phases. If the nexus transfer phase is implemented, synchronous data transfer shall be implemented in both the target and the initiator. It shall be used in these phases if a synchronous data transfer agreement has been established (see 6.e.26). The agreement specifies the REQ/ACK offset and the minimum transfer period. The REQ/ACK offset specifies the maximum number of REQ pulses that can be sent by the target in advance of the number of ACK pulses received from the initiator, establishing a pacing mechanism. If the number of REQ pulses exceeds the number of ACK pulses by the REQ/ACK offset, the target shall not assert the REQ signal until after the leading edge of the next ACK pulse is received. A requirement for successful completion of the data phase is that the number of ACK and REQ pulses be equal. The target shall assert the REQ signal for a minimum of an assertion period. The target shall then wait at least the greater of a transfer period from the last transition of the REQ signal to true or a minimum of a negation period from the last transition of the REQ signal to false before again asserting the REQ signal. The initiator shall send one pulse on the ACK signal for each REQ pulse received. The ACK signal may be asserted as soon as the leading edge of the corresponding REQ pulse has been received. The initiator shall assert the ACK signal for a minimum of an assertion period. The initiator shall wait at least the greater of a transfer period from the last transition of the ACK signal to true or for a minimum of a negation period from the last transition of the ACK signal to false before asserting the ACK signal. If the I/O signal is true (transfer to the initiator), the target shall first drive the DB(7-0,P) signals to their desired values, wait at least one deskew delay plus one cable skew delay, then assert the REQ signals. The DB(7-0,P) signals shall be held valid for a minimum of one deskew delay plus one cable skew delay plus one hold time after the assertion of the REQ signal. The target shall assert the REQ signal for a minimum of an assertion period. The target may then negate the REQ signal and change or release the DB(7-0,P) signals. The initiator shall read the value on the DB(7-0,P) signals within one hold time of the transition of the REQ signal to true. The initiator shall then respond with an ACK pulse. 41 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 If the I/O signal is false (transfer to the target), the initiator shall transfer one byte for each REQ pulse received. After receiving the leading edge of a REQ pulse, the initiator shall first drive the DB(7-0,P) signals to their desired values, delay at least one deskew delay plus one cable skew delay, then assert the ACK signal. The initiator shall hold the DB(7-0,P) signals valid for at least one deskew delay plus one cable skew delay plus one hold time after the assertion of the ACK signal. The initiator shall assert the ACK signal for a minimum of an assertion period. The initiator may then negate the ACK signal and may change or release the DB(7-0,P) signals. The target shall read the value of the DB(7-0,P) signals within one hold time of the transition of the ACK signal to true. IMPLEMENTORS NOTE: The description in SCSI-1 allowed some implementors to presume that the leading edge of the first REQ pulse beyond the REQ/ACK offset agreement would not occur until after the trailing edge of the last ACK pulse within the agreement. Devices implemented with this understanding may be subject to data destruction when in synchronous data transfer mode with devices that issue the leading edge of the next REQ pulse, at the boundary of the agreement, as soon as the leading edge of the last ACK pulse within the agreement is received. Implementors using devices of the former type in initiator designs may insure data integrity by restricting the synchronous offset agreement to values smaller than the maximum nominally offered by their device. 5.1.5.3. Wide Data Transfer Wide data transfer is optional and may be used in the data phase and the nexus transfer phase only if a nonzero wide data transfer agreement is in effect (see WIDE DATA TRANSFER REQUEST message, 6.e.29). The messages determine the use of wide mode by both SCSI devices and establish a data path width to be used during the DATA phase. Wide data transfers of 16- or 32-bits may be established. Although not mandatory, it is recommended that targets and initiators that support 32-bit wide transfers also support 16-bit wide transfers as well. All SCSI devices shall support 8-bit data transfers. During 16-bit wide data transfers, the first logical data byte for each data phase shall be transferred across the DB(7-0,P) signals on the A cable and the second logical data byte shall be transferred across the DB(15-8,P1) signals on the B cable. Subsequent pairs of data bytes are likewise transferred in parallel across the A and B cables (see Figure 5-1). During 32-bit wide data transfers, the first logical data byte for each data phase shall be transferred across the DB(7-0,P) signals on the A cable and the second, third, and fourth logical data bytes shall be transferred across the DB(15-8,P1), DB(23-16,P2), and DB(31-24,P3) signals, respectively, on the B cable. Subsequent groups of four data bytes are likewise transferred in parallel across the A and B cables (see Figure 5-1). When transferring bytes W, X, Y and Z across the three bus widths, they are transferred as shown below: 42 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Hand- 8-bit 16-bit 32-bit shake # A Cable B Cable A Cable <------ B Cable ------> A Cable +-------+ +---------------+ +------------------------------- 1 | W | | X | W | | Z | Y | X | W | |-------| |-------|-------| +------------------------------- 2 | X | | Z | Y | 31...24 23...16 15....8 7....0 |-------| +---------------+ 3 | Y | 15....8 7.....0 Bit Number |-------| 4 | Z | Bit Number +-------+ 7.....0 Bit Number NOTE: This figure does not represent how these bytes are stored in the initiator's memory, which may be different. Figure 5-1: Wide SCSI Byte Ordering If the last data byte transferred for a command does not fall on the DB(15- 8,P1) signals for a 16-bit wide transfer or the DB(31-24,P3) signals for a 32- bit wide transfer, then the values of the remaining higher-numbered bits are undefined. However, parity bits for these undefined bytes shall be valid for whatever data is placed on the bus. To ensure proper data integrity, certain sequence requirements shall be met between the REQ/ACK handshakes on the A cable and the REQB/ACKB handshakes on the B cable: (1) The REQB and ACKB signals shall only be asserted during data phases while a nonzero wide data transfer agreement is in effect. These signals shall not be asserted during other phases. (2) The same information transfer mode (asynchronous or synchronous) shall be used for both the A cable and the B cable. If synchronous data transfer mode is in effect, the same REQ/ACK offset and transfer period shall be used for both cables. (3) The information transfer procedures defined in 5.1.5.1 and 5.1.5.2 for the A cable (the REQ, ACK, and DB(7-0,P) signals) shall also apply to the B cable (the REQB, ACKB, and DB(31-8,P1,P2,P3) signals). The only means available for a target to manage the timing relationship between the signals on the two cables is its management of the REQ and REQB signals. Similarly, the only means for the initiator to manage the timing between the two cables is its management of the ACK and ACKB signals. (4) The target shall ensure that the number of REQ/ACK handshakes and the number of REQB/ACKB handshakes in a data phase are equal before it changes to another phase. The target shall not change the phase until the ACK and ACKB signals have both become false for the last REQ/ACK handshake and the last REQB/ACKB handshake. 43 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 IMPLEMENTORS NOTE: If any violations of these rules are detected by the target, the target may attempt to end the data phase and return CHECK CONDITION status. If it is impossible to correctly terminate the data phase, the target may abnormally terminate the I/O process by an unexpected disconnect. If any violations of these rules are detected by the initiator, the initiator may attempt to send an INITIATOR DETECTED ERROR message to the target. If the initiator is unable to terminate the I/O process normally, it may generate the reset condition. 5.1.6. COMMAND Phase The COMMAND phase allows the target to request command information from the initiator. Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D signal and negate the I/O and MSG signals during the REQ/ACK handshake(s) of this phase. 5.1.7. Data Phase The data phase is a term that encompasses both the DATA IN phase and the DATA OUT phase. Each SCSI device shall maintain the state of the transfer agreements for asynchronous, synchronous, and wide data transfer for each SCSI device it is capable of communicating with. The default state shall be asynchronous transfer mode, one byte wide. 5.1.7.1. DATA IN Phase The DATA IN phase allows the target to request that data be sent to the initiator from the target. Synchronous data transfer and wide data transfer may be used during this phase per the established or default agreements. The target shall assert the I/O signal and negate the C/D and MSG signals during the REQ/ACK handshake(s) of this phase. 5.1.7.2. DATA OUT Phase The DATA OUT phase allows the target to request that data be sent from the initiator to the target. Synchronous data transfer and wide data transfer may be used during this phase per the established or default agreements. The target shall negate the C/D, I/O, and MSG signals during the REQ/ACK handshake(s) of this phase. 5.1.8. STATUS Phase 44 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The STATUS phase allows the target to request that status information be sent from the target to the initiator. Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D and I/O signals and negate the MSG signal during the REQ/ACK handshake of this phase. 5.1.9. Message Phase The message phase is a term that references either a MESSAGE IN, or a MESSAGE OUT phase. Multiple messages may be sent during either phase. The first byte transferred in either of these phases shall be either a single-byte message or the first byte of a multiple-byte message. For multiple-byte messages, all bytes of the message shall be transferred within a single message phase. An alternate procedure for handling message parity errors is outlined in Section 6.e.21. The alternate procedure is symmetrical for initiators and targets. 5.1.9.1. MESSAGE IN Phase The MESSAGE IN phase allows the target to request that message(s) be sent to the initiator from the target. Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D, I/O, and MSG signals during the REQ/ACK handshake(s) of this phase. If the initiator detects one or more parity error(s) on the message byte(s) received, it may indicate its desire to retry the message(s) by asserting the the ATN signal, causing the target to transfer a MESSAGE PARITY ERROR message from the initiator in a MESSAGE OUT phase. The target, upon detecting this message, shall resend all of the previous message byte(s) in the same order as previously sent during this phase. The initiator may process a message as received as long as no parity error is detected in any byte of the message and may ignore all remaining messages sent after a parity error is detected. When a sequence of messages is resent by a target because of an initiator detected parity error, the initiator shall not reprocess any message which it has previously processed. If the initiator receives all of the message byte(s) successfully (i.e., no parity errors), it shall indicate that it does not wish to retry by not asserting ATN. The initiator may also indicate that it has successfully received and processed the message byte(s) by asserting the ATN signal and transferring any other message(s) (e.g., NO OPERATION). 5.1.9.2. MESSAGE OUT Phase 45 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The MESSAGE OUT phase allows the target to request that message(s) be sent from the initiator to the target. The target invokes this phase in response to the attention condition created by the initiator when not using the nexus transfer phases (see 5.2.2). Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D and MSG signals and negate the I/O signal during the REQ/ACK handshake(s) of this phase. The target shall handshake byte(s) in this phase until the ATN signal is negated, except when rejecting a message. If the target detects one or more parity error(s) on the message byte(s) received, it may indicate its desire to retry the message(s) by asserting the REQ signal after detecting the ATN signal has gone false and prior to changing to any other phase. The initiator, upon detecting this condition, shall resend all of the previous message byte(s) in the same order as previously sent during this phase. When resending more than one message byte, the initiator shall assert the ATN signal at least two deskew delays prior to asserting the ACK signal on the first byte and shall maintain the ATN signal asserted until the last byte is sent as described in 5.2.2. The target may process messages as received as long as no parity error is detected in any byte of the message and shall ignore all remaining messages sent under one ATN condition after a parity error is detected. When a sequence of messages is resent by an initiator because of a target detected parity error, the target shall not reprocess any message which it has previously processed. If the target receives all of the message byte(s) successfully (i.e., no parity errors), it shall indicate that it does not wish to retry by changing to any information transfer phase other than the MESSAGE OUT phase and transfer at least one byte. The target may also indicate that it has successfully processed the message byte(s) by changing to the BUS FREE phase (e.g., ABORT or BUS DEVICE RESET messages). The initiator shall follow the action specified in Table 5-2 for controlling the attention condition when processing the identified messages. For multiple byte messages, the action is taken on the last byte of the message during the MESSAGE OUT phase. 46 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 5-2: Message Codes with Special Initiator Action ================================================================== Initiator Initiator Negate ATN Msg Support Before Code Level Message Name Last ACK ------------------------------------------------------------------ 06h O ABORT Yes 0Dh O ABORT TAG Yes 0Ch O BUS DEVICE RESET Yes 0Eh O CLEAR QUEUE Yes 04h O -DISCONNECT Yes *** O +EXTENDED MESSAGE REJECT Yes 0Fh O INITIATE RECOVERY Yes 05h M INITIATOR DETECTED ERROR Yes 25h O INVALID BUS PHASE DETECTED (Two Bytes) Yes 09h M -MESSAGE PARITY ERROR Yes 07h M -MESSAGE REJECT Yes 08h M -NO OPERATION Yes 24h O PARITY ERROR (Two Bytes) Yes 10h O RELEASE RECOVERY Yes 26h O +RESEND PREVIOUS INFORMATION PACKET Yes *** O SYNCHRONOUS DATA TRANSFER REQUEST Yes *** O +SYNCHRONOUS PACKET TRANSFER REQUEST Yes 11h O TERMINATE I/O PROCESS Yes *** O WIDE DATA TRANSFER REQUEST Yes ================================================================== ---------------------------------------------------------------------- Key: M = Mandatory support, O = Optional support. Yes = Initiator shall negate ATN before last ACK of message. + = Used only with NEXUS TRANSFER phase protocol - = Not used with NEXUS TRANSFER phase protocol *** = Extended message (see Section 6) 80h+ = Codes 80h through FFh are used for IDENTIFY messages (see Section 6). ---------------------------------------------------------------------- 5.1.10. Nexus Transfer Phase The nexus transfer phase is a term that encompasses the NEXUS TRANSFER IN phase and the NEXUS TRANSFER OUT phase. 5.1.10.1. NEXUS TRANSFER IN Phase The NEXUS TRANSFER IN phase allows the target to request that information packet(s) be sent to the initiator from the target. This phase may be used instead of the MESSAGE IN, STATUS, and DATA IN phases when the data are formed into information packets. The processing of messages is altered using this phase. 47 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Synchronous data transfer and wide data transfer may be used during this phase. The target shall assert the I/O, and MSG signals and negate the C/D signal during the REQ/ACK handshake(s) of this phase. 5.1.10.1. NEXUS TRANSFER OUT Phase The NEXUS TRANSFER OUT phase allows the target to request that information packet(s) be sent from the initiator to the target. This phase may be used instead of the MESSAGE OUT, COMMAND, and DATA OUT phases when the data are formed into information packets. The processing of messages is altered using this phase. Synchronous data transfer and wide data transfer may be used during this phase. The target shall assert the MSG signal and negate the C/D and I/O signals during the REQ/ACK handshake(s) of this phase. 5.1.11. Signal Restrictions Between Phases When the SCSI bus is between two information transfer phases, the following restrictions shall apply to the SCSI bus signals: (1) The BSY, SEL, REQ, REQB, ACK and ACKB signals shall not change. (2) The C/D, I/O, MSG, and DATA BUS signals may change. When switching the DATA BUS direction from out (initiator driving) to in (target driving), the target shall delay driving the DATA BUS by at least a data release delay plus a bus settle delay after asserting the I/O signal and the initiator shall release the DATA BUS no later than a data release delay after the transition of the I/O signal to true. When switching the DATA BUS direction from in (target driving) to out (initiator driving), the target shall release the DATA BUS no later than a deskew delay after negating the I/O signal. (3) The ATN and RST signals may change as defined under the descriptions for the attention condition (see 5.2.2) and reset condition (see 5.2.3). 5.2. Parallel Interface SCSI Bus Conditions The SCSI bus has three asynchronous conditions: the unexpected BUS FREE condition; the attention condition and the reset condition. These conditions cause the SCSI device to perform certain actions and can alter the phase sequence. Furthermore, an SCSI device may not all be powered on at the same time. This standard does not address power sequencing issues. However, each SCSI device, as it is powered on, should perform appropriate internal reset operations and internal test operations. It is recommended that following a power-on to selection time after power is applied, SCSI targets be able to 48 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 respond with appropriate status and sense data to the TEST UNIT READY, INQUIRY, and REQUEST SENSE commands. 5.2.1. Initiator Detected Unexpected BUS FREE Condition If an initiator detects the release of the BSY signal by the target at any other time than for the conditions in Section 5.1.1, the target is indicating the unexpected BUSS FREE error condition to the initiator. The target may perform this transition to the BUS FREE phase independent of the state of the ATN signal. The initiator shall manage this condition as an unsuccessful I/O process termination (See 6.j.5.). 5.2.2. Attention Condition When not using the nexus transfer phase, the attention condition allows an initiator to inform a target during a connection that the initiator has a message ready. The target may get this message by performing a MESSAGE OUT phase. The initiator creates the attention condition by asserting ATN at any time except during the ARBITRATION or BUS FREE phases. When using the nexus transfer phase, the attention condition allows the initiator to inform the target during a connection that it has an information packet to send. The target gets this information packet by performing a NEXUS TRANSFER OUT phase. The initiator creates the attention condition by asserting ATN at any time except during the BUS FREE phase or during the transfer of the first byte of each information transfer packet when using the NEXUS TRANSFER IN phase. The use of ATN for the first byte of a NEXUS TRANSFER IN phase is to inform a target that the initiator does not implement the nexus transfer phases. That is, the initiator has detected an illegal phase. 5.2.2.1. ATN Signal and the Message Phase The initiator shall assert the ATN signal at least two deskew delays before negating the ACK signal for the last byte transferred in a bus phase for the attention condition to be honored before transition to a new bus phase. Asserting the ATN signal later might not be honored until a later bus phase and then may not result in the expected action. The initiator shall negate the ATN signal at least two deskew delays before asserting the ACK signal while transferring the last byte of the messages indicated with a "Yes" in Table 5-2 under the column heading "Negate ATN Before Last ACK." If the target detects that the initiator failed to meet this requirement, then the target shall go to BUS FREE phase (see unexpected disconnect, 5.2.1). A target shall respond with MESSAGE OUT phase as follows: (1) If the ATN signal becomes true during a COMMAND phase, the target shall enter MESSAGE OUT phase after transferring part or all of the command descriptor block bytes. (2) If the ATN signal becomes true during a DATA phase, the target shall enter MESSAGE OUT phase at the target's earliest convenience (often, but not 49 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 necessarily on a logical block boundary). The initiator shall continue REQ/ACK handshakes with valid data until it detects the phase change. (3) If the ATN signal becomes true during a STATUS phase, the target shall enter MESSAGE OUT phase after the status byte has been acknowledged by the initiator. (4) If the ATN signal becomes true during a SELECTION phase and before the initiator releases the BSY signal, the target shall enter MESSAGE OUT phase immediately after that SELECTION phase. (5) If the ATN signal becomes true during a RESELECTION phase, the target shall enter MESSAGE OUT phase after the target has sent its IDENTIFY message for that RESELECTION phase. The initiator shall keep the ATN signal asserted if more than one byte is to be transferred. The initiator may negate the ATN signal at any time except it shall not negate the ATN signal while the ACK signal is asserted during a MESSAGE OUT phase. Normally, the initiator negates the ATN signal while the REQ signal is true and the ACK signal is false during the last REQ/ACK handshake of the MESSAGE OUT phase. 5.2.2.2. ATN Signal and the Nexus Transfer Phase The initiator shall assert the ATN signal at least two deskew delays before negating the ACK signal for the last byte transferred in a bus phase for the attention condition to be honored before transition to the BUS FREE phase or a new nexus transfer phase. Asserting the ATN signal later might not be honored until a later information packet in the same or a new connection and then may not result in the expected action. The initiator shall not assert the ATN signal on the first byte of a NEXUS TRANSFER IN phase, except to indicate that it does not support the nexus transfer phases. A target shall respond with NEXUS TRANSFER OUT phase as follows: (1) If the ATN signal becomes true during a DATA phase, the target shall enter NEXUS TRANSFER OUT phase at the target's earliest convenience (often, but not necessarily on a logical block boundary). The initiator shall continue REQ/ACK handshakes with valid data until it detects the phase change. (2) If the ATN signal becomes true during a nexus transfer phase, the target shall enter NEXUS TRANSFER OUT phase at the target's earliest convenience (often, but not necessarily on a logical block boundary). The initiator shall continue REQ/ACK handshakes with valid data until it detects the phase change. (3) If the ATN signal becomes true during a SELECTION phase and before the initiator releases the BSY signal, the target shall enter NEXUS TRANSFER OUT phase immediately after that SELECTION phase. 50 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 (4) If the ATN signal becomes true during a RESELECTION phase, the target shall enter NEXUS TRANSFER OUT phase immediately following that RESELECTION phase. 6.j.6. Reset Condition The reset condition is used to immediately clear all SCSI devices from the bus. This condition shall take precedence over all other phases and conditions. Any SCSI device may create the reset condition by asserting the RST signal for a minimum of a reset hold time. During the reset condition, the state of all SCSI bus signals other than the RST signal is not defined. All SCSI devices shall release all SCSI bus signals (except the RST signal) within a bus clear delay of the transition of the RST signal to true. The BUS FREE phase always follows the reset condition. See section 6.j.6 for the effect on logical operations. 5.3. Parallel Interface SCSI Bus Phase Sequences The order in which phases are used on the SCSI bus follows a prescribed sequence. The reset condition can abort any phase, except a BUS FREE phase, and is always followed by the BUS FREE phase. Also any other phase can be followed by the BUS FREE phase but many such instances are error conditions (see unexpected disconnect condition, 5.2.1). If the bus is not in the BUS FREE phase after the reset condition, then further operation with the SCSI bus is impossible. Another reset may be attempted. The additional allowable sequences shall be as shown in Figure 5-2. The normal progression is from the BUS FREE phase to ARBITRATION, from ARBITRATION to SELECTION or RESELECTION, and from SELECTION or RESELECTION to one or more of the information transfer phases. When not using the nexus transfer phase, the final information transfer phase is normally the MESSAGE IN phase where a DISCONNECT, or COMMAND COMPLETE message is transferred, followed by the BUS FREE phase. When using the nexus transfer phase, each phase is followed by a BUS FREE phase or another execution of the nexus transfer phase. 51 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 +---------------+ +--| NEXUS |<-+ +---------------------+ +->| TRANSFER | | | | Reset or | | IN or OUT |<-+----+---+ +--------V------+ protocol | +---------------+ | | | +----> |------+ error | | | | |+---> MESSAGE OUT |---+ | | V | | | || +-> | | | | +<--------------------+----+---+---++-+-| |--+| | | | | or | | || | +----A----------+ || | | | +---------------+ | || | +--------V------+ || | | | ------| | | || | | | || | | | | | SELECTION | | ||++-> COMMAND |--++-+| | | | | | | |||| | |-+|| || | | | | | | |||| | | ||| || | | | +-------A-------+ | |||| +---------------+ ||| || +--V----V----V--+ +---------------+ | |||| +--------V------+ ||| || | | | | | ||+--| | ||| || | BUS FREE |---> ARBITRATION | | |||+-> DATA IN or <-+++-++ | | | | | |||| | DATA OUT | ||| | | | | | | |||| | |-++++| +-------A----A--+ +---------------+ | |||| +---------------+ ||||| | | +-------V-------+ | |||| +--------V------+ ||||| | | | | | |||| | | ||||| | +------| RESELECTION | | |+++-| STATUS <-+|||| | | | | | || | | |||| | | | | | || | <--+||| | +---------------+ | | || +----A----------+ ||| | | | | | || +--------V------+ ||| | | or | | | |+-| <---+|| | | +-----+ | +--| MESSAGE IN <----+| | | +----| | | | | | <-----+ | | +--A------------+ | | | | | +----------------------+ | +-------------------------------------------------+ The word "or" in the figure indicates a mutually exclusive choice of phase sets during a connection. Figure 5-2: Phase Sequences 5.4. Serial Interface SCSI Bus Phases The SCSI architecture includes two distinct phases: BUS FREE phase NEXUS TRANSFER phase The SCSI bus, as determined at a SCSI port, can never be in more than one phase at any given time. Since there is no direct signal protocol exchange 52 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 between SCSI device ports, traditional signal protocols are not applicable, and the nexus and connection concepts of the parallel interface must be modified. An active serial interface consists of a continuous stream of encoded bytes transmitted along one conductor between a source and a destination. Since there are two conductors for each SCSI device port, the other conductor is transmitting a continuous stream of encoded byte values from the destination to the source. The receiving device port may not be aware that it is about to receive an information packet. The sending SCSI device port may not be aware of the present state of the destination SCSI device port. For point-to-point implementations without switches, the source has complete control of when an information packet is placed into this stream of encoded bytes. The destination also has complete control of when an information packet is placed into the stream of encoded bytes on the reverse conductor. All switches, including string switches, control the point when an information packet is placed into the stream of encoded byte on one of its send conductors. The switch must first detect the BUS FREE phase for the appropriate conductor. When the BUS FREE phase is detected, the switch may then place a pending information packet into the send conductor encoded byte stream of the appropriate SCSI bus. Because of the two independent conductors in the serial interface for an SCSI device port, the discussions below apply independently to each conductor. For each information packet successfully received, the receiving SCSI port shall acknowledge receipt by sending an acknowledge information packet on the reverse conductor. This acknowledgement is normally transmitted by the SCSI port hardware. For each information packet received which contains a logical error, but which is otherwise received error free, the receiving SCSI port shall send an acknowledge with error information packet on the reverse conductor. The receiving SCSI port shall not process this information packet further and shall not retain it. This acknowledgement with error is normally transmitted by the SCSI port hardware. For each information packet received with a physical error, such as a CRC error, the receiving SCSI port shall not acknowledge receipt of the information packet and shall neither process the information packet further nor retain it. 5.4.1. BUS FREE Phase The BUS FREE phase is used to indicate that no SCSI device is actively using the SCSI bus and that it is available. 53 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 SCSI devices shall detect the BUS FREE phase when the idle encoded byte character has been detected for the specified number of bytes. SCSI ports normally do not expect BUS FREE phase to begin except after one of the following occurrences: (1) after the transfer of a complete information packet in the nexus transfer phase. If a receiving SCSI port detects the BUS FREE phase at any other time, the sending SCSI port may have no idea that an error has occurred in the transmission of the information packet. the receiving SCSI port. The information packet is not acknowledged. Upon detecting the missing information packet, the sending SCSI port shall manage this condition as an unsuccessful information packet transfer. The sending SCSI port: 1) may attempt to retransmit the information packet in error some sending SCSI port determined number of retries. 2) if it is 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 shall prepare sense data. 3) if it is operating in initiator mode for the I/O process, shall abort the I/O process. It is recommended that the initiator then request sense information from the target. 5.4.2. Information Transfer Phase The NEXUS TRANSFER phases are known as the information transfer phases because they are all used to transfer data or control information via the SCSI bus. The actual content of the information is beyond the scope of this section. In parallel interfaces and in SCSI-2, the MESSAGE, COMMAND, DATA phases, and STATUS phase were used to identify the type of data being transferred at different points during a connection. In the serial interface the nexus transfer phases are used for all transfers. Two phases of the same type may be processed back-to-back provided that there is a pause containing encoded idle characters between the information packets of a specified number of bytes. 54 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 5-3: Serial Interface Information Transfer Phases ================================================================= Phase Name Direction Of Transfer Comment ----------------------------------------------------------------- NEXUS TRANSFER OUT Initiator to target Nexus NEXUS TRANSFER IN Initiator from target Transfer Phase ================================================================= 5.4.3. Synchronous Data Transfer The nexus transfer phase, by virtue of the manner in which it is transmitted, is always in the form of synchronous data transfer. Synchronous data transfer is the only mode of operation for the serial SCSI port. The offset between source and destination is logically controlled by the number of information packets outstanding, rather than the number of bytes, as for the parallel interface. 5.4.4. Nexus Transfer Phase The nexus transfer phase is a term that encompasses the NEXUS TRANSFER IN phase and the NEXUS TRANSFER OUT phase. 5.4.4.1. NEXUS TRANSFER IN Phase The NEXUS TRANSFER IN phase allows the target to send information packet(s) to the initiator. Synchronous data transfer is always used during this phase. No SDTR negotiation is possible or defined. The target shall insert an information packet on its inbound/send conductor when it has an information packet pending and the idle encoded character has been detected for a specified number of bytes. 5.4.4.2. NEXUS TRANSFER OUT Phase The NEXUS TRANSFER OUT phase allows the initiator to send information packet(s) to a target. Synchronous data transfer is always used during this phase. No SDTR negotiation is possible or defined. The initiator shall insert an information packet on its outbound or send conductor when it has an information packet pending and the idle encoded character has been detected for a specified number of bytes. 5.4.5. Signal Restrictions Between Phases 55 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 When the SCSI bus is between two information transfer phases, the following restrictions shall apply: (1) The sending SCSI port shall wait until a specified number of idle encoded characters have been transferred on the conductor before attempting to send another information packet. 5.5. Serial Interface SCSI Bus Conditions The SCSI bus has one asynchronous condition; the reset condition. This condition causes the SCSI device to perform certain actions. SCSI devices may not all be powered on at the same time. This standard does not address power sequencing issues. However, each SCSI device, as it is powered on, should perform appropriate internal reset operations and internal test operations. It is recommended that, following power-on sequence or a reset condition, SCSI devices be able to respond with appropriate status and sense data to the TEST UNIT READY, INQUIRY, and REQUEST SENSE commands within xx seconds. 5.5.1. Reset Condition The reset condition is used to immediately clear all SCSI devices from the bus. This condition shall take precedence over all other phases and conditions. Any SCSI device may create the reset condition by broadcasting a reset information packet. Upon receipt of the reset information packet, all SCSI devices shall perform an unexpected disconnect on their send conductors if they are actively sending an information packet. The BUS FREE phase always follows the reset condition. See Section 6.j.6 for the effect of the Reset condition on logical operations. 5.6. Serial Interface SCSI Bus Phase Sequences The order in which phases are used on the SCSI bus follows a prescribed sequence. The reset condition can abort a nexus transfer phase, and it is always followed by the BUS FREE phase. Also any nexus transfer phase can be followed by the BUS FREE phase. If the bus is not in the BUS FREE phase after the reset condition, further operation of the I/O process on an SCSI port attached to that bus shall not be attempted. The allowable sequences shall be as shown in Figure 5-3. The normal progression is from the BUS FREE phase to one of the nexus transfer phases for each conductor. The nexus transfer phase used is determined by whether the SCSI port is in initiator mode or target mode. For initiator mode, the 56 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 phase used is NEXUS TRANSFER OUT. For target mode, the phase is NEXUS TRANSFER IN. The SCSI port shall use only the BUS FREE phase and one of the nexus transfer phases, as appropriate, until the mode of the SCSI port is changed. Each phase is followed by a BUS FREE phase or another execution of a nexus transfer phase. +---------------+ +--| NEXUS | | | TRANSFER |<-+ Reset or +->| IN or OUT | | protocol | +---------------+ | error | | | | | | | | | | +---------------+ | | | | | | | +->| BUS FREE |--+ +-------->| | | | +---------------+ Figure 5-3: Serial Interface Phase Sequences 57 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 58 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 6. SCSI Logical Operations This section is divided into 7 parts: 1) Logical operations model in section 6.1; 2) Information packet description in section 6.2.; 2) SCSI pointers in section 6.3; 4) Message system description in Section 6.4 through 6.5; 5) Commands and Status in Section 6.6 through 6.9; 6) Exception Conditions in Section 6.10 through 6.13; 7) Queued I/O processes in Section 6.14. The 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, and status. The interface logical elements for SCSI-2 are not formed in to self describing units, when using the SCSI-2 information transfer protocol. The variable length nature of interface logical elements is generally variable to the initiator for inbound transfers and some outbound data transfers. The target has only one variable interface logical element and that is outbound messages. This potentially requires a higher level of interaction between the physical layer and logical operations. With the information packet structure, all operations are accomplished by placing descriptors in an information packet which are interpreted by the initiator or target. Parity errors are handled by retransmitting the information packet. The initial information packet transfers on the parallel SCSI bus, are in asynchronous data transfer mode. For serial interface implementations, all transfers are in synchronous data transfer mode. When implementing information packets, there are additional requirements: 1) All SCSI devices shall implement an active initiator mode and an active target mode (i.e., dynamic switching of the SCSI port mode). 2) All SCSI devices shall implement synchronous data transfer. For parallel interface implementations, each SCSI device port shall negotiate for and be granted synchronous data transfer mode. For serial implementations, synchronous data transfer mode is the only transfer mode on the SCSI bus. 3) Initiators shall respond correctly to asynchronous event notification. This permits dynamic changes to the logical system over time and earlier problem determination. 59 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 4) Targets shall implement asynchronous event notification. Events not occurring in the confines of an I/O process are reported when they occur. 5) A SCSI device port which normally acts as an initiator, when selected, shall enter target mode and shall declare itself as an appropriate device class in response to the INQUIRY command. Usually the device class is reported as processor to permit asynchronous event notification. 6) The target controller shall implement the initiator mode on each port so that it can select the initiators to acquire the INQUIRY data to determine its active initiators, provide asynchronous event notification, and declare itself a SCSI device which uses information packets. 6.1. Logical Operation Model The logical operation model describes device-independent activity using one or more SCSI busses. The next section provides a glossary related to the logical operations model. The glossary is followed by the logical operation model description. 6.1.1 Glossary for Logical Operation Model assigned. An attribute of a logical unit or target routine where it responds to I/O processes only for certain path groups. disband. A function which breaks up a set of paths established as a path group. dynamic path status mode. A condition in initiators and targets where any status is transferred on any path in the path group where a connect is made. The status may or may not lead to a contingent allegiance. establish. A function in target controllers where a non-empty set of paths is treated as equivalent, or grouped, for most I/O process activity. grouped. The state of a path when it is included in an established path group. The path group must contain at least one path. 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 which indicates the routes I/O processes may take between an initiating controller and a logical unit or target routine. password. An identifier used to permit otherwise unauthorized access to a logical unit or target routine. path. A path is a named physical link between an initiating controller and a logical unit or target routine. At least one connect has been made from the initiaging controller to the logical unit or target routine. The name consists of a ICID, an SCSI ID for the initiator, an SCSI ID for the target controller, the port of the target controller where the connect occurs, and the LUN or TRN of the selected logical unit or target routine. 60 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 path group. A path group is a logical path formed as a cooperating unit. 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. The condition is reset when the I/O process completes. single path status mode. A condition in a path group where status leading to a contingent allegiance is transferred on the path where the connect occurred. An implicit path or an ungrouped path is in single path status mode since it cannot cooperate with any other path in either state. singular. An attribute of an SCSI 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. supervisor command. A command which may not be executed by a target controller unless specifically authorized. unassigned. An attribute of a logical unit or target routine where it is permitted to respond to I/O processes on any path. ungrouped. The state of a path when it is not included in an established path group. 61 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Attributes of a Minimum Logical System Initiating Controller Target Controller ICID Target Controller Port Number SCSI Address SCSI Address SCSI ID (parallel intf.) SCSI ID (parallel intf.) Logical Unit LUN Initiator - Target - SCSI Device in SCSI Device in Initiator Mode Target Mode +-----+ +-----+ | | | | | P | | P | | O |----------------------------| O | | R | | R | | T | SCSI Bus | T | | | | | +-----+ +-----+ Path = ICID || Initiator SCSI Address || Target SCSI Address || Target Controller Port Number || LUN Logical path = ICID || LUN Path implicitly defined Path in the Ungrouped State Path Group is Not Established Path Ststus is Implicitly Named Path Single path status mode LUN is Unassigned No password exists Figure 6.c. MINIMUM LOGICAL SYSTEM ATTRIBUTES 62 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 6.1.2. Logical Operation Model Description A logical system consists seventeen (17) items as follows: 1) a minimum of two SCSI ports and one SCSI bus connecting them; 2) a minimum of one SCSI port must be capable of operating in initiator mode (called an initiator); 3) a minimum of one SCSI port must be capable of operating in target mode (called a target); 4) the initiator and target in 2) and 3) above, attach to the same SCSI bus and are active in their respective modes during a connection between them (i.e., not the same port); 5) the logical element attaching an SCSI device which principally starts I/O processes is called an initiating controller. 6) the logical element attaching an SCSI device which principally receives and executes I/O processes is called a target controller; NOTE: The names given to the logical elements attaching an SCSI device do not preclude any SCSI device from using all functions of SCSI. The word "principally" in items 5) and 6) imply 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. This is the peer capability of SCSI as opposed to a master-slave relationship on some other I/O busses. 7) each port has an SCSI address unique to the SCSI bus on which it is attached; the SCSI address translates to the physical SCSI ID on some bus implementations. 8) each port, when acting as a target, has a port number assigned by the target controller. The port number is unique within a target controller; 9) each initiating controller is assigned an initiating controller ID. An initiating controller ID (ICID) must be unique in a logical system to prevent unpredictable results; 10) each target controller has one or more logical units each identified by a unique Logical Unit Number (LUN). 11) each target has zero or more target routines each identified by a target routine number (TRN). 12) the extent of a logical system, from the viewpoint of a target controller, is the set of all initiating controllers having at least one port attached via a SCSI bus to at least one port of the target controller and from which a connect has been made. From the point of view of the initiating controller, the extent of a logical system is the set of all logical unit and target routines to which a 63 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 connect has been made. The set of paths available to any one logical unit or target routine is determined from the results of the INQUIRY command response data and the REPORT PATH STATUS command response data. NOTE: A balanced logical system may consist of two SCSI busses with two ports for the initiating controller and two ports for the target controller. One port of each logical element attaches to one SCSI bus. This configuration provides a redundant path from the initiating controller to each logical unit in the target controller. 13) An identifier consisting of a ICID, an initiator SCSI address, a target controller SCSI address, a target controller port number, and a LUN or TRN, defines a path when the relationship is established as the result of a connect started by an initiating controller to a target controller. The LUN or TRN must be valid for the target controller. The logical unit need not be ready or installed (e.g., unpowered but cabled or uncabled). No path exists between a LUN or TRN and an initiating controller unless the LUN or TRN is explicitly the object of a connect started by that initiating controller to the LUN or TRN. NOTE: A connect using Asynchronous Event Notification does not define a path from the initiating controller to the logical unit or target routine. The logical unit or target routine must be selected as the receiver of an I/O process by the initiating controller. AEN uses a physical path between the target controller, with one port in initiator mode, and a initiating controller, with one port in target mode. From the target controller's point of view, an implicit path is defined as a result of the successful connect from the target controller to the initiating controller. Such a path may be developed in accordance with the Logical Operations Model as needed by the target controller based on the implemented function of the initiating controller when operating in target mode. 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. An explicitly named path exists when the initiating controller successfully completes an I/O process to transfer the ICID of the initiating controller to the LUN or TRN. NOTE: All actions and functions below which refer to implicitly named paths have equivalent functions in SCSI-2. Any function in the logical operations model referring to an explicitly named path does not exist in SCSI-2. 14) 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 a set of one or more paths. An initiating controller connects with and transfers its ICID to each logical unit and target routine. 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 paths it intends to use for 64 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 dynamic path operations or for which it intends to perform assignment operations other than for the one path. NOTE: In the balanced logical system above, each initiating controller must connect with each LUN on two paths and transfer its ICID on each path to establish the set of explicitly named paths. Explicitly naming a set of paths to a LUN or TRN from the same initiating controller does not establish a path group for conducting dynamic path operations. An explicitly named path is initially in the ungrouped state relative to other paths in the logical path. An implicitly named path stays in an ungrouped state since the target cannot identify the initiating controller. Each initiator connecting with each target controller port must be considered as attached to a unique initiating controller until the transfer of an ICID from the initiating controller occurs. 15) A set of ungrouped explicitly named paths in a logical path is established 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 or logical path, when established as a group, is called a path group. Establishing a path group is a singular operation. 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 a path group by a command from the initiating controller on that path. 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 system 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 command. The logical path remains as it did before the path group was established. Disbanding a path group is a singular operation. Once a path group is established with two or more paths, the pointers for an active I/O process must be in a position to be shared between the initiators in the initiating controller servicing the paths in the path group. NOTE: If no path group is established which contains two or more paths, SCSI pointer management in each initiator remains the same as in SCSI-2, since the target controller is restricted to operations only on the path where the connect occurred. Once a path group is established, the extended functions of assignment and dynamic pathing operations may be used. The initiating controller determines whether either or both functions are used. The target controller by accepting the enabling commands has indicated that it is capable of participating in these functions. 65 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Including a path in a path group does not restrict access to the logical unit or target routine from any other path. Establishing a path gorup is a naming process. Access is limited by the assignment function described in item 16 below. Once a path group is established, it may be important to control the path where status leading to a contingent allegiance is reported. This is especially true if the main recovery mechanism for all I/O processes is located on one path and other paths are treated like data highways by the initiating controller. Therefore, a function of establishing path groups is to identify where status leading to a contingent allegiance is reported. Any status which does not result in contingent allegiance may be sent over any path in the path group. The condition may be altered by disbanding the group and establishing the group with the alternate choice. The initiating controller is given two choices: 1) single path status mode is an initiating controller established condition in both the initiating controller and the target controller where status resulting in contingent allegiance is sent only over the path on which the connect was made; 2) dynamic path status mode is an initiating controller established condition in both the initiating controller and the target controller where status is sent over the next available path in the established path group. When an implicitly named path, an ungrouped path, or a path group containing only one path is used to make a connect, dynamic path operation is not permitted. As a result, single path status mode is in effect. When operating in dynamic path status mode, an initiating controller may temporarily switch to single path mode for an I/O process without affecting the established path group. The function is in effect for all linked commands in an I/O process. In addition to single path status mode, all activity related to the I/O process must occur on the path where the connect was made. The function is called suspend dynamic path operation. The state of the path may be any one of the following: 1) Implicitly named path. No explicit ICID has been received from an initiating controller to any LUN or TRN on this target controller from the initiator SCSI ID/target port combination. An I/O process received on a path in this state is required to perform all operations on this path. 2) Path to Other LUNs. An explicitly named path to at least one LUN or TRN on this initiator SCSI ID/target port, other than the selected logical unit or target routine, exists. This is functionally equivalent to 1) but it imparts additional information to the initiating controller. An I/O process received on a path in this state is required to perform all operations on this path. 3) Ungrouped. An explicitly named path to the selected LUN or TRN exists but it is not currently part of an established path group. An I/O process received on a path in this state is required to perform all operations on this path. 66 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 4) Grouped. An explicitly named path to the selected LUN or TRN exists and is currently established in the grouped state. The path group can consist of one or more paths. An I/O process received on this path may respond on any path in this path group unless single path status is in effect or dynamic path reconnection has been temporarily suspended for an I/O process. Both the initiating controller and the target controller must keep track of the paths, path groups, the state of each path in the group, and the status transfer mode for each LUN or TRN. Both must communicate on the appropriate paths and the target controller must be prepared to report the state of any path to the initiating controller. All path groups are established and managed by the functions defined above save one exception condition which is described in item 17. Path identification and grouping is not a supervisor mode operation since it does not restrict access to the LUNs in a target controller. 16) Any logical unit, target routine or extent attached to an SCSI bus is initially available to receive I/O processes from any initiating controller attached to that SCSI bus. This use priviledge is extended whether the path is explicitly named, implicitly named, and whether for explicitly named paths, the path is grouped or ungrouped. This state of access is logically equivalent to the SCSI-2 bus with no reservations outstanding. Such unrestricted access may not be appropriate for environments with extensive multi-user access and/or data bases with sensitive information. Therefore, it is appropriate to control access to a LUN logical unit, target routine or an extent within a logical unit at a higher level than the RESERVE/RELEASE functions defined in SCSI-2. The ability to control use priviledges requires requires path group control when multiple SCSI busses are involved. Two or more explicitly defined path groups may share use priviledges to the exclusion of other path groups. A single path group may hold exclusive use priviledges. Use priviledeges are controlled with two functions called assign and unassign. Because of the implications to system reliability and integrity, these functions are defined as supervisor commands. Their purpose is to act as the logical equivalent of switches or manual cable changes to restrict access to logical units, target routines, or extents within logical units. Assignment to one path group means that no initiating controller on any path not in the path group can gain access to the logical unit using the functions defined to this point. Certain commands, such as REQUEST SENSE and INQUIRY may be responded to regardless of the source of the command. A logical unit may be assigned to multiple established path groups. An implicitly named path or an ungrouped path can gain assignment for itself, but it cannot add assignment for any other paths or path groups. Any path holding assignment through an established path group may add assignment of other established path groups. The two functions of assignment are: 67 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 1) assign this LUN to the path group on which the command was received, or 2) add assignment of this LUN for another established path group. The inverse of assign is unassign. Use priviledges may be unassigned from any path group to which assignment currently exists from any path for which assignment currently exists. Assignment may be transferred from one initiating controller to another without passing through a state where no assignment exists. Initiating controllers, through their use of the path naming functions and grouping functions, may be assigned use priviledges or they may be unassigned. The mechanism by which an initiating controller obtains the path group name required for adding or removing assignment of additional path groups is not established by or a concern of the logical system. 17) The provision for assignment permits multiple initiating controllers to control use priviledges. The last function in the logical operations model concerns breaking an assignment if some error or failure in an initiating controller which currently has assignment. The break may be temporary or permanent, but it must be controlled, as are other functions which can lead to reliability, availability, and data integrity problems. This function, above all the rest, requires supervisor mode. This is not a singular function. Assignment permits use priviledges through assigned path groups. Controlled access is a function which permits access outside the bounds of defined assignment functions. The mechanism to prevent deliberate or accidental loss of assignment protection is the control access function, enabled by a password, and checked by the affected target controller. A password is established by an initiating controller having assignment. The password is not reported by a target controller on any path. The target controller 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 a password established and it matches the password with the command, the control access command and any commands linked to it are executed, if possible. The mechanism by which the unassigned initiating controller acquires the correct password is not established by or a concern of the logical system. The control access command has three functions: 1) establish a password in a target controller. The command must be received on a path currently holding assignment. 2) general unassign. The control access command is received from a path that does have assignment. If no password has been set or the password supplied matches the password in the target, the target controller removes assignment for all paths in any path group having assignment when the command was processed. The result is that the logical unit, target routine, or extent has no assignment protection. 68 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 3) request temporary unassignment. The control access command is received from a path that does not have assignment. If the password matches the password in the target controller, commands linked to the control access command are executed to the extent possible. A status which would lead to contingent allegiance on the unassigned path is not permitted, since that would grant the unassigned path permission to continue operations with a REQUEST SENSE command to retrieve the sense data. The contingent allegiance is made with an assigned path whether functional or not. When a request for temporary assignment is granted, the issuing initiating controller may link to an assign command which will grant assignment to the once unassigned initiating controller. The initiating controller can then use normal I/O processes. An I/O process containing a valid control access command requesting temporary assignment, a control access command performing a general unassign, and an assign command for the new initiating controller breaks all old assignments and transfers assignment of the LUN to the new initiating controller. This operation permits continued operation without loss of the function provided by the logical unit. Some I/O processes may be aborted. 6.2. Information Packet Structure An information packet is an ordered set of self-describing interface logical elements surrounded by the appropriate interface control fields necessary to transmit the logical content of the packet a selected physical bus (Table 6-d). For the parallel interface, the maximum information packet length is 2**32 - 1 bytes. For the serial interface, the maximum information packet length is 2112 bytes. Table 6-d: Information Packet Structure =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-m| Interface Control Prefix Fields | -----|------------------------------------------------------------| m+1-n| Message Interface Logical Element | -----|------------------------------------------------------------| n+1-p| Zero or more Interface Logical Elements | -----|------------------------------------------------------------| p+1-q| Interface Control Suffix Fields | =================================================================== 6.2.1. Interface Control Fields 6.2.1.1. Interface Control Fields (Parallel) 69 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The reasons for the parallel bus interface control fields being of different length and make up than the serial bus interface control fields are: that the two SCSI ports, the source and destination of the information packet, are in direct contact on the SCSI bus; the connection established between the two SCSI ports indicates that the source and destination addresses are valid; CRC is not required on the parallel bus; and parity is checked as the transfer occurs. Table 6-e: Interface Control Prefix Fields (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0 | (MSB) | -----|--- ---| 1 | | -----|--- Packet Length ---| 2 | | -----|--- ---| 3 | (LSB) | -----|------------------------------------------------------------| 4 | Packet Type | -----|------------------------------------------------------------| 5 |LUNTAR|MltPath|QNexus| Reserved | -----|------------------------------------------------------------| 6 | Original Initiator SCSI Address | -----|------------------------------------------------------------| 7 | Original Target SCSI Address | -----|------------------------------------------------------------| 8 | LUNTRNID | -----|------------------------------------------------------------| 9 | Target Port Number | -----|------------------------------------------------------------| 10 | Queue tag | -----|------------------------------------------------------------| 11 | Reserved | -----|------------------------------------------------------------| 12-n| TBD | =================================================================== 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 a function of the selected physical interface and may be further restricted by maximum burst length negotiations. The packet type field identifies the general content of an information packet. A packet type code of 00h indicates an information packet to start a new nexus. A packet type code of 01h indicates a target initiated packet to terminate an I/O process. A packet type code of 02h indicates an 70 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 intermediate information packet from an initiator to continue an I/O process established with an information packet of type 00h. 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. 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 an asynchronous event notification condition or a unit attention condition. Packet type code of 05h through FFh are reserved. A logical unit target (LUNTAR) bit of zero specifies that the I/O process is directed to or from a logical unit. A LUNTAR bit of one specifies that the I/O process is directed to or from a target routine. The logical unit or target routine is identified in the LUNTRNID field. When sent by a target 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 LUNTAR bit is set as appropriate for a connect for asynchronous event notification. A multiple path (MltPath) bit of one specifies that the initiating controller is capable of multiple path operation. The effect is to form an H_C nexus on the connect. Multiple path operation is interpreted as active for each nexus when the bit is set to 1. The type of nexus may be modified by the INFORMATION PACKET IDENTIFY message within the information packet, in which case, the target controller converts the H_C nexus to an H_I_T_C nexus. The setting has no effect on any other active or queued I/O process in the target controller. When the bit is set to zero, the target controller forms an H_I_T_C nexus immediately and ignores the SuspMpth bit in the INFORMATION PACKET IDENTIFY message. This value shall remain unchanged in all information packets for the nexus. The queue nexus (QNexus) bit when one indicates that the nexus will be of the form H_C_L_Q or H_I_T_C_Q. When the queue nexus bit is zero, the nexus formed will be of the form H_C_L, H_C_R, H_I_T_C_L, or H_I_T_C_R. The next five fields identify the path on which the connect was made for the nexus. The LUNTAR bit identifies whether the nexus is directed toward a logical unit or a target routine. These five fields shall not change in any information packet of any type transferred for the nexus once established as specified below. These five fields and the LUNTAR bit, identify the nexus to be reestablished in any subsequent connection on any path for the nexus, and likewise in the target controller, when operating in a multiple path environment. The original initiator SCSI address identifies the port on the initiating controller where the connect was made using an information packet packet type code of 00h. The original target SCSI address identifies the port, from the initiator's perspective, where the connect was made using an information packet packet type code of 00h. 71 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The target port number identifies the physical port number assigned by the target controller to the target SCSI address. This field shall be zero when the packet type code is 00h. The target shall supply its unique port value in any subsequent information packet. Once the initiating controller receives an information packet for the nexus, all subsequent information packets shall have the target reported value placed in this field. If the disconnect privilege is not granted to a target controller, the target port number may not be transferred until the information packet with a packet type of 01h is transferred. The target controller may receive multiple information packets during the connect with a value of 00h. The logical unit number target routine number (LUNTRNID) field specifies a logical unit number if the LUNTAR bit is zero. The LUNTRNID field specifies a target routine number if the LUNTAR bit is one. The response to an invalid value in the LUNTRNID field is described in 6.10.3. The queue tag field is identical to the queue tag value in any queue tag messages transferred during the nexus. This 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 sending an information packet with an INVALID INFORMATION PACKET message. There are no interface control suffix fields for the parallel bus. 6.2.1.2. Interface Control Fields (Serial) Table 6-f: Interface Control Prefix Fields (Serial) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-n | TBD | =================================================================== The format of the interface control prefix fields are subject to standardization in other ANSI committees and will be added or referred to at a later time. =================================================================== Byte | Description | =================================================================== 0-n | TBD | =================================================================== The format of the interface control suffix fields are subject to standardization in other ANSI committees and will be added or referred to at a later time. 72 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The interface control suffix fields are not permitted on the parallel bus and mandatory on the serial bus. 6.2.2. Interface Logical Elements The logical interface elements are messages, command descriptor blocks, command parameter data, command response data, logical blocks, and status as described in Sections 6 though 17 of this standard. A self-describing set of fields surrounds the data, called interface control fields, to permit the information packet to be correctly identified and checked at the receiving SCSI port. The information packet does not remove any functional capability from the SCSI interface. Some functions are no longer required, or there is a substitute way of accomplishing the same function when using information packets. A self-describing logical interface element is composed of four fields: the element length, the element type, a reserved field, and the logical element bytes. An information packet shall contain at least one interface logical element and shall not contain more than 255 interface logical elements. Table 6-h: Self-Describing Interface Logical Element =================================================================== Byte | Description | =================================================================== 0 | | ----------|--- Element Length ---| 1 | | ----------|-------------------------------------------------------| 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 with respect to the physical bus requirements for the maximum packet length. 73 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The element type is a one-byte binary field. The value range is 0 through 5. The valid value are defined below. Table 6-i: Element Types ELEMENT TYPE VALUE INTERFACE LOGICAL ELEMENT 0 Message 1 CDB 2 Command Parameter Data 3 Command Response Data 4 Logical Block 5 Status 6 - 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 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 relative to 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.2.2.1. Message Interface Logical Element The message logical interface element includes all messages defined in the message system and applicable to the physical bus and protocol implemented. The element bytes are filled in with the message bytes in the order which they would be transferred on a single byte wide bus. See sections 6.4 and 6.5 for the message descriptions and their use. 6.2.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 defined in Sections 7 through 17 of this standard. Command parameter data is transferred in its own interface logical element. 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.2.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 parameter data in the parameter length fields, etc. 74 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 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.2.2.4. Command Response Data Interface Logical Element The command response data interface logical element is a burst of data transferred from a target to an initiator 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. 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.2.2.5. Logical Block Interface Logical Element The logical block interface logical element consists of a burst of data from the logical blocks requested for transfer between an initiator and a target. The logical block interface logical element is roughly equivalent to a burst of bytes. 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.2.2.6. Status Interface Logical Element The status interface logical element is the status as defined in Section 6.8 of this standard. The element bytes are filled in with status in the order which they would be transferred on a single byte wide bus. 6.2.3. Information Packet Layout 6.2.3.1. Parallel Bus The parallel bus information packet layout consists of the following minimum structures: one information control prefix structure and one message interface logical element immediately following the interface control prefix structure are mandatory. The message interface logical element shall contain messages and message sequences following the rules of the message system (6.4 and 6.5). There is no interface control suffix structure on for the parallel bus information packet (Table 6-j). The remainder of the information packet is made up of zero or more interface logical elements, as required to perform the operations for the I/O process. 75 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-j: Information Packet Structure (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-m| Interface Control Prefix Fields (Parallel) | -----|------------------------------------------------------------| m+1-n| Message Interface Logical Element | -----|------------------------------------------------------------| n+1-p| Zero or more Interface Logical Elements | =================================================================== 6.2.3.2. Serial Bus TBD Table 6-k: Information Packet Structure (Serial) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-m| Interface Control Prefix Fields (Serial) | -----|------------------------------------------------------------| m+1-n| Message Interface Logical Element | -----|------------------------------------------------------------| n+1-p| Zero or more Interface Logical Elements | -----|------------------------------------------------------------| p+1-q| Interface Control Suffix Fields (Serial) | =================================================================== 6.2.4. Information Packet Examples The following two information packets comprise a complete nexus for causing a rewind command to be executed in a sequential access device. The first information packet is a request for a sequential device to perform a rewind operation while the initiator waits with no disconnect permitted. The total exchange requires 68 bytes to be transferred. Each information packet is 34 bytes long. The SCSI-2 protocol requires 9 bytes total: 7 bytes from the in and 2 bytes from the target. If disconnect were allowed the total would be 10 bytes with the target controller transferring 3 bytes. The percent of bytes for overhead is reduced as data transfer commands are mapped into the new protocol. This structure, in properly configured systems permits reconnection on any path in an established path group on which the connect was made. The new capability is almost mandatory when using the serial bus since multiple path configurations happen as a matter of course with the point-to-point switches. The SCSI-2 protocol cannot be extended, easily, to accommodate the new requirements. 76 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-l: Initial Information Packet Example (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0 | (MSB) | -----|--- ---| 1 | | -----|--- Packet Length ---| 2 | 00000022h | -----|--- ---| 3 | (LSB) | -----|------------------------------------------------------------| 4 | Packet Type | | 00H (Initiate I/O Process) | -----|------------------------------------------------------------| 5 |LUNTAR|MltPath|QNexus| Reserved | | 0 0 0 00000 | -----|------------------------------------------------------------| 6 | Original Initiator SCSI Address | | 07h | -----|------------------------------------------------------------| 7 | Original Target SCSI Address | | 01h | -----|------------------------------------------------------------| 8 | LUNTRNID | | 00h | -----|------------------------------------------------------------| 9 | Target Port Number | | 00h | -----|------------------------------------------------------------| 10 | Queue tag | | 00h | -----|------------------------------------------------------------| 11 | Reserved | | 00h | =================================================================== 77 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-m: Initial Information Packet Example Cont'd (Parallel) =================================================================== Byte | Message Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 000Ch | ----------|-------------------------------------------------------| 2 | Element Type | | 00h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-11 | Element Bytes | | 01h | | 08h | | 05h | | 00h | | 00h | | 07h | | 01h | | 00h | =================================================================== Table 6-n: Initial Information Packet Example Cont'd (Parallel) =================================================================== Byte | CDB Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 000Ah | ----------|-------------------------------------------------------| 2 | Element Type | | 01h | ----------|-------------------------------------------------------| 3 | Reserved | | 001h | ----------|-------------------------------------------------------| 4-9 | Element Bytes | | 01h (Sequential Rewind) | | 00h | | 00h | | 00h | | 00h | | 00h | =================================================================== The sequential device performs the rewind operation without disconnecting and then sends the following information packet during the initial connection. The information packet is 34 bytes long. and includes the interface control prefix fields, the INFORMATION PACKET IDENTIFY message 78 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 interface logical element, the status interface logical element and the COMMAND complete message interface logical element. Table 6-o: Response Information Packet Example (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0 | (MSB) | -----|--- ---| 1 | | -----|--- Packet Length ---| 2 | 00000022h | -----|--- ---| 3 | (LSB) | -----|------------------------------------------------------------| 4 | Packet Type | | 01h (Terminate I/O Process) | -----|------------------------------------------------------------| 5 |LUNTAR|MltPath|QNexus| Reserved | | 0 0 0 00000 | -----|------------------------------------------------------------| 6 | Original Initiator SCSI Address | | 07h | -----|------------------------------------------------------------| 7 | Original Target SCSI Address | | 01h | -----|------------------------------------------------------------| 8 | LUNTRNID | | 00h | -----|------------------------------------------------------------| 9 | Target Port Number | | 04h (Internal Port Number) | -----|------------------------------------------------------------| 10 | Queue tag | | 00h | -----|------------------------------------------------------------| 11 | Reserved | | 00h | =================================================================== 79 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-p: Response Information Packet Example Cont'd (Parallel) =================================================================== Byte | Message Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 000Ch | ----------|-------------------------------------------------------| 2 | Element Type | | 00h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-11 | Element Bytes | | 01h | | 08h | | 05h | | 00h | | 00h | | 07h | | 01h | | 00h | =================================================================== Table 6-q: Response Information Packet Example Cont'd (Parallel) =================================================================== Byte | Status Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 0005h | ----------|-------------------------------------------------------| 2 | Element Type | | 05h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-9 | Element Bytes | | 00h (Good) | =================================================================== 80 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-r: Response Information Packet Example Cont'd (Parallel) =================================================================== Byte | Message Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 0005h | ----------|-------------------------------------------------------| 2 | Element Type | | 00h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-11 | Element Bytes | | 00h (Command Complete) | =================================================================== 6.3. SCSI Pointers 6.3.1. Parallel Interface SCSI Pointers Consider the logical system shown in Figure 6-a in which an initiating controller and a target controller communicate on the SCSI bus in order to execute an I/O process. ------------------------- ------------------------ |Initiating| | Initiator|-----------------| Target | | Target | |Controller| | SCSI Bus | SCSI BUS | SCSI Bus | |Cotroller| | | | Control |-----------------| Control | | | ------------------------- ------------------------ Initiator Target Figure 6-a: Simplified SCSI Logical System The SCSI architecture provides for a set of three pointers for each active I/O process, called the saved pointers. The set of three pointers consist of one for the command, one for the data, and one for the status. The saved pointers are a resource of the initiating controller and may reside in the initiator when multiple port operations are not being performed or they may reside in an area common to each initiator in the path group where the connect was made for an I/O process. For each new I/O process established in an initiating controller, the initial state of the saved pointers shall be established at the time that the connect is made. When the initial connection ocurs, the saved pointers are copied in to the active pointer area of the initiator. A similar initiator action occurs at each subsequent reconnection for the i/O process. 81 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 When multiple path operations are being performed during an I/O process, the saved pointers shall be available to all initiators in the path group where the commect was made. When multiple path operations are not implemented, are suspended, or the path group contains only one path, the saved pointers may reside in the initiator where the the connect for the I/O process was made. When an active I/O process becomes the current I/O process, its three saved pointers are automatically copied by the initiator into the initiator's set of three active pointers. There is only one set of active pointers in each initiator. The active pointers point to the next command, data, or status byte to be transferred between the initiator and the target for the current I/O process. The active pointers reside in the initiator. When information packets are used for an I/O process, only the data pointer is actively used since the other pointers for commands and status are not used. The command and status pointer are managed by the initiator to keep track of the progress of an I/O process, but they are not useful in information packet transfers. The saved command pointer always points to the start of the current command descriptor block for each active I/O process. The current command is defined as the command of the I/O process executing in the target controller. With the queued commands, this pointer only has meaning, for operation of the SCSI bus, during the connection in which the command descriptor block(s) is transferred. With information packets, the command pointer has no meaning for the operation of the SCSI bus. The saved status pointer always points to the start of the status area for the current command of each active I/O process. The status pointer has no meaning for the operation of the SCSI bus when using information packets. The initiator shall update the pointer as each status is transferred. The saved data pointer points to the start of the data area until the target transfers a SAVE DATA POINTER message (see 6.5.26) for the current command of the current I/O process or until disconnect in an information packet transfer and a data interface logical element was contained in the information packet. For either of these conditions, the data pointer is advanced to the next byte to be transferred for the current command of the I/O process during a subsequent data transfer. When an initiator receives a SAVE DATA POINTER message, it stores the value of the active data pointer into the saved data pointer for the current I/O process. The target may restore the active pointers to the saved pointer values for the current I/O process by sending a RESTORE POINTERS message (see 6.5.25) to the initiator. The initiator then copies the set of saved pointers into the set of active pointers. When a target disconnects from the bus, only the set of saved pointers for the active I/O process are retained. The set of active pointers is restored from the set of saved pointers automatically upon reconnection which changes an active I/O process to the current I/O process. No RESTORE POINTERS message needs to be sent from the target to cause the pointers to be restored after RESELECTION. 82 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 When using information packets, the initiator stores the value of the active data pointer into the saved data pointer for the current I/O process at the end of each information packet transfer. The correct saved pointers are automatically restored at the beginning of each reconnection. If the initiating controller implements the MODIFY DATA POINTER MESSAGE, the target may modify the active data pointer by sending a MODIFY DATA POINTER message (see 6.5.19) to the initiator as part of an information packet. The initiator then adjusts the data pointer in the set of active pointers. When a target disconnects, only the set of saved pointers, copied from the active pointers for the active I/O process, is retained. The set of active pointers is restored from the set of saved pointers automatically upon reconnection, which changes an active I/O process to the current I/O process. The data pointer value may be modified by the target before the I/O process ends and, therefore, it should not be used to test for actual transfer length. 6.3.2. Serial Interface SCSI Pointers Consider the system shown in Figure 6-b in which an initiator and target communicate on the SCSI bus to execute an I/O process. ------------------------- ------------------------- | Function | | Initiator|<----------------| Target | | Function | | Origin | | SCSI Bus | SCSI BUS | SCSI Bus | | Execution| | | | Control |---------------->| Control | | | ------------------------- ------------------------- Initiator Target Figure 6-b: Simplified SCSI System The SCSI architecture provides for a set of three pointers for each active I/O process when the SCSI port is operating in initiator mode, called the saved pointers. The pointers are not used when the same port is in target mode and they shall not be changed while the port is in target mode. The saved pointers are a resource of the initiating controller, and they may reside in an initiator, or they may reside in an area available to the ports managing an established path group where the connect was made for an the I/O process. If multiple path operations are implemented, the saved pointers must reside in a common area shared by the initiators for the path group where the connect for each I/O process is made. If multiple path operations are not implemented, are suspended, or the path group consists of only one path, the saved pointers may reside in either place. The set of three saved pointers consists of one for the current command, one for the data associated with the current command, and one for the status 83 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 for the current command. The current command is the one executing in the target. The pointers move through the various parts of an I/O process based on actions taken by the target as it executes the I/O process. The data pointer is the only pointer which actively changes during the execution of a command in a target. The command and status pointers are reset to the next command or status area as status for each command as it is completed. Commands, status, and data are transmitted on information packet boundaries and therefore the pointers cannot follow in a byte-by-byte fashion, as in the parallel interface. There is only one set of active pointers in each initiator. The active pointers reside in the SCSI port and are used during a connection when the port is in initiator mode. Of the active pointers, only the data pointer is used during a connection to point to the next position where a data interface logical element may be read into or transferred from between the initiator and the target for the current I/O process. When an active I/O process becomes the current I/O process, its saved pointers are automatically transferred into the initiator's set of active pointers. The saved command pointer always points to the start of the current command descriptor block (see 6.3) for each active I/O process. With queued commands and information packets, this pointer only has meaning to the initiator and the initiating controller. The pointer is updated by the initiator as the I/O process executes. The saved status pointer always points to the start of the status area for the current command of each active I/O process. The saved data pointer points to the start of the data area for the current command until the acknowledgement information packet is received for an information packet which contained a data interface logical element sent to a target. The saved data pointer points to the start of the data area for the current command until an information packet which contains a data interface logical element sent from a target is received without error. The data pointer is automatically saved at the end of either of these two operations. The correct saved pointers pointers are automatically restored at the beginning of each information packet transfer. The target may modify the active data pointer by sending a MODIFY DATA POINTER message (see 6.5.19) to the initiator as part of an information packet. The initiator then adjusts the data pointer in the set of active pointers. Data can then be retransmitted to replace data already transmitted to the initiator or the target. To cause the data pointer to be saved, the information packet must contain a data logical interface element. When each information packet is processed, only the set of saved pointers for the active I/O process is retained. The set of active pointers is restored from the set of saved pointers automatically upon reconnection. Reconnection changes an active I/O process to the current I/O process. 84 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The data pointer value may be modified by the target at any time before the command status is transferred and, therefore, it should not be used to test for actual transfer length. The queue of commands for the I/O process in the initiating controller must be managed according to which ones have been executed, which ones have been transferred to the target if queued I/O processes are being used, and which ones are yet to be transferred to the target for immediate execution or for execution based on the queue tags. The mechanism for management of the status of an I/O process other than the saved and active pointers, described above, is beyond the scope of this standard. 6.4. Message System Description The message system allows communication between an initiator and target of information not contained in the other interface logical elements (e.g., commands). A message interface logical element may be one, two, or multiple bytes in length. When the initiator and target are notusing information packets, one or more messages may be sent during a single MESSAGE phase. A multiple-byte message may not be split over MESSAGE phases. The initiator is required, when using the message phase, to end the attention condition when it sends certain messages as identified in Table 6-s. When using informatin packets, one or more messages may be transferred along with other interface logical elements in a single information packet. A multiple-byte message may not be split over information packets or between message interface logical elements in one information packet. The initiator is required to control the length of the message logical interface elements in an information packet when it sends certain messages as identified in Table 6-s. Such information packets shall not contain any other interface logical elements. The end of the attention condition in information packets is logically transmitted by the end of the message interface logical element and the end of the information packet (including the interface control suffix, if any). One-byte, Two-byte, and extended message formats are defined. The first byte of the message determines the format as follows: Value Message Format --------- ----------------------------------- 00h One-Byte Message (COMMAND COMPLETE) 01h Extended Messages 02h - 1Fh One-Byte Messages 20h - 2Fh Two-Byte Messages 30h - 7Fh Reserved 80h - FFh One-Byte Message (IDENTIFY) 85 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 All initiators shall implement the mandatory messages tabulated in the "Init" column of Table 6-s for information packet operations. All targets shall implement the mandatory messages tabulated in the "Targ" column of Table 6-s for information packet operations. This is modified by the presence of the "+" and "-" symbols before each message name with the meanings defined in Table 6-s. 86 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-s: Message Codes ========================================================================= End Code Support Message Name Direction Attention Init Targ Condition ------------------------------------------------------------------------- 06h O M ABORT Out Yes 0Dh O O ABORT TAG (Note 1) Out Yes 0Ch O M BUS DEVICE RESET Out Yes 0Eh O O CLEAR QUEUE (Note 1) Out Yes 00h M M COMMAND COMPLETE In --- 04h O O -DISCONNECT In --- 04h O O -DISCONNECT Out Yes *** O O +EXTENDED MESSAGE REJECT In Out Yes 80h+ M O -IDENTIFY In --- 80h+ M M -IDENTIFY Out --- 23h O O IGNORE WIDE RESIDUE (Two Bytes) In --- *** O O +INFORMATION PACKET IDENTIFY In Out --- 0Fh O O INITIATE RECOVERY In --- 0Fh O O INITIATE RECOVERY (Note 2) Out Yes 05h M M INITIATOR DETECTED ERROR Out Yes 25h O O INVALID BUS PHASE DETECTED (Two Bytes) In Out Yes *** O O +INVALID INFORMATION PACKET In Out --- 0Ah O O LINKED COMMAND COMPLETE In --- 0Bh O O LINKED COMMAND COMPLETE (WITH FLAG) In --- 09h M M -MESSAGE PARITY ERROR In --- 09h M M -MESSAGE PARITY ERROR Out Yes 07h M M -MESSAGE REJECT In Out Yes *** O O MODIFY DATA POINTER In --- 08h M M -NO OPERATION Out Yes 24h O O PARITY ERROR (Two Bytes) In Out Yes Queue Tag Messages (Two Bytes) 21h O O HEAD OF QUEUE TAG Out --- 22h O O ORDERED QUEUE TAG Out --- 20h O O SIMPLE QUEUE TAG In Out --- 10h O O RELEASE RECOVERY Out Yes 26h O O +RESEND PREVIOUS INFORMATION PACKET In Out Yes 03h O O -RESTORE POINTERS In --- 02h O O -SAVE DATA POINTER In --- *** O O SYNCHRONOUS DATA TRANSFER REQUEST In Out Yes *** O O +SYNCHRONOUS PACKET TRANSFER REQUEST In Out Yes 11h O O TERMINATE I/O PROCESS Out Yes *** O O WIDE DATA TRANSFER REQUEST In Out Yes 12h - 1Fh Reserved 27h - 2FH Reserved for two-byte messages 30h - 7Fh Reserved ========================================================================= 87 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Key: M = Mandatory support, O = Optional support. In = Target to initiator, Out = Initiator to target. Yes = Initiator ends the attention condition. --- = Not Applicable + = Used only with information packet protocol - = Not used with information packet protocol *** = Extended message (see Tables 6-a and 6-u) 80h+ = Codes 80h through FFh are used for IDENTIFY messages. NOTES: (1) The ABORT TAG and CLEAR QUEUE messages are required if tagged queuing is implemented. (2) Outbound INITIATE RECOVERY messages are only valid during the asynchronous event notification protocol. ------------------------------------------------------------------------------ One-byte messages consist of a single byte where the value of the byte determines which function is to be performed as defined in Table 6-s. 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 sent for an extended message is three. The extended message format and the extended message codes are shown in Tables 6-t and 6-u, respectively. 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. Table 6-t: Extended Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | n | Extended message length | ----------|----------|-------------------------------------------------------| 2 | y | Extended message code | ----------|----------|-------------------------------------------------------| 3 - n+1 | x | Extended message arguments | ============================================================================== The extended message length specifies the length in bytes of the extended message code plus the extended message arguments to follow. Therefore, the 88 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 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. The extended message codes are listed in Table 6-u. The extended message arguments are specified within the extended message descriptions. Table 6-u: Extended Message Codes ============================================================================== Code (y) Description ------------------------------------------------------------------------------ 02h Reserved (See Note) 00h MODIFY DATA POINTER 01h SYNCHRONOUS DATA TRANSFER REQUEST 03h WIDE DATA TRANSFER REQUEST 04h EXTENDED MESSAGE REJECT 05h INFORMATION PACKET IDENTIFY 06h INVALID INFORMATION PACKET 07h SYNCHRONOUS PACKET TRANSFER REQUEST 08h - 7Fh Reserved 80h - FFh Vendor Unique ============================================================================== NOTE: Extended message code 02h was used for the EXTENDED IDENTIFY message in SCSI-1. 6.4.1. Message Use when not Using Information Packets The first message sent by the initiator after a connection shall be an IDENTIFY, ABORT, or BUS DEVICE RESET message. If a target receives any other message it shall disconnect (see unexpected disconnect, 5.1.1). If the first message is an IDENTIFY message, then it may be immediately followed by other messages, such as the first of a pair of SYNCHRONOUS DATA TRANSFER REQUEST messages. If tagged queuing is used the queue tag message immediately follows the IDENTIFY message (see 6.5.8). The IDENTIFY message establishes a logical connection between the initiator and the specified logical unit or target routine within the target known as an I_T_L nexus or I_T_R nexus. After reconnection, the target's first message shall be IDENTIFY. This allows the I_T_L nexus or I_T_R nexus to be re-established. Only one logical unit or target routine shall be identified for any connection; if a target receives a second IDENTIFY message with a different logical unit number or target routine number during a connection, it shall disconnect (see unexpected disconnect, 5.1.1). The treatment of other logical unit addressing errors is described in 6.10. Whenever an I_T_L nexus or I_T_R nexus is established by an initiator that is allowing disconnection, the initiator shall ensure that the active pointers are equal to the saved pointers for that particular logical unit or target routine. An implied restore pointers operation shall occur as a result of a reconnection. 89 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 6.4.2. Message Use with Information Packets The first interface logical element in each information packet shall be a message interface logical element with the first or only message being INFORMATION PACKET IDENTIFY, ABORT, or BUS DEVICE RESET message. If a target receives any other interface logical element before a message interface logical element, it shall not process the contents of the information packet and shall transfer an information packet containing an an INVALID INFORMATION PACKET message. If the target receives any other message before one of the named messages in the first message interface logical element, it shall not process the contents of the information packet and shall transfer an information packet containing an EXTENDED MESSAGE REJECT message. If the first interface logical element is a message group and the first message is an INFORMATION PACKET IDENTIFY message, then it may be immediately followed by other messages, such as a SYNCHRONOUS PACKET TRANSFER REQUEST messages. If tagged queuing is used for the nexus, the queue tag message immediately follows the INFORMATION PACKET IDENTIFY message (see 6.5.10). The INFORMATION PACKET IDENTIFY message establishes a logical connection between the initiating controller and the specified logical unit or target routine within the target known as an H_C_L nexus, an H_C_R nexus, an I_T_L nexus or I_T_R nexus. Only one logical unit or target routine shall be identified for any one information packet; if a target receives a second IDENTIFY message with a different logical unit number or target routine number in one information packet, it shall not process the remainder of the information packet beyond the point of the invalid INFORMATION PACKET IDENTIFY message. The treatment of other logical unit addressing errors is described in 6.10. 6.4.2.1. Message Use with Information Packets (Parallel) After reconnection, the target's first information transfer phase shall an information packet containing as the first interface logical element an INFORMATION PACKET IDENTIFY message. This allows the H_C_L nexus, H_C_R nexus, I_T_L nexus or I_T_R nexus to be re-established. Additional messages may follow the INFORMATION PACKET IDENTIFY message in the interface logical element. Whenever an H_C_L nexus, an H_C_R nexus, an I_T_L nexus, or I_T_R nexus is established by an initiator that is allowing disconnection, the initiator shall ensure that the active pointers are equal to the saved pointers for that particular logical unit or target routine. An automatic implied restore pointers operation shall occur in the initiator as a result of a new information packet for the same I/O process or a reconnection to the same I/O process. 6.4.2.2. Message Use with Information Packets (Serial) Each target sent information packet shall contain, as the first interface logical element, an INFORMATION PACKET IDENTIFY message. This allows the H_C_L nexus, H_C_R nexus, I_T_L nexus or I_T_R nexus to be re-established. Additional messages may follow the INFORMATION PACKET IDENTIFY message in the interface logical element. 90 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Whenever an H_C_L nexus, an H_C_R nexus, an I_T_L nexus, or I_T_R nexus is reestablished by a target the initiator shall ensure that the active pointers are equal to the saved pointers for that particular logical unit or target routine. An automatic implied restore pointers operation shall occur in the initiator as a result of each new information packet for the same I/O process or a reconnection to the same I/O process. 6.5. Message Descriptions The SCSI messages are defined in this section. The requirements for implementation are given in Table 6-s. Additional messages shall be implemented when certain SCSI functions are implemented. These messages are identified in Table 6-s for information packets and in the message descriptions. Because of the close link between the physical protocol and the message system in SCSI-2, there are many references to the specific protocol phases in the text which follows. When using information packets, the physical interface protocol is separeted from message handling and this results in fewer or no references to the physical protocol for message transfer. 6.5.1. ABORT The ABORT message is sent from the initiator to the target to clear the active I/O process plus any queued I/O process for the H_C_x nexus or I_T_x nexus. Pending data, status, and queued I/O processes for any other H_C_X nexus or I_T_x nexus shall not be cleared. When this messages is received during a message phase, the target shall disconnect following successful processing of this message. When this message is treansferred in an information packet, there is no change to the physical interface as a result of successful processing. If only an H_C nexus or I_T nexus has been established, the target shall disconnect if the MESSAGE OUT phase is used to transmit the message. 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 an H_C_x nexus or I_T_x nexus that does not have an active or queued I/O process. Previously established conditions, including MODE SELECT parameters, reservations, and extended contingent allegiance shall not be changed by the ABORT message. IMPLEMENTORS NOTES: The BUS DEVICE RESET, CLEAR QUEUE, ABORT, and ABORT TAG messages provide a means to clear one or more I/O processes prior to normal termination. The BUS DEVICE RESET message clears all I/O processes for all initiators on all logical units and all target routines of the target. The CLEAR QUEUE message clears all I/O processes for all initiators on the specified logical unit or target routine of the target. The ABORT message clears all I/O processes for the selecting initiator on 91 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 the specified logical unit or target routine of the target. The ABORT TAG message clears the active I/O process only. 6.5.2. ABORT TAG The ABORT TAG message shall be implemented if tagged queuing is implemented. The target shall disconnect following successful receipt of this message if the MESSAGE OUT phase is used to transfer the message. The target shall clear the I/O process identified. If the target has already started execution of the I/O process, the execution shall be halted. The medium contents may have been modified before the execution was halted. In either case, any pending status or data for the I/O process shall be cleared and no status or ending message shall be sent to the initiator. Pending status, data, and commands for other active or queued I/O processes shall not be affected. Execution of other I/O processes queued for the H_C_x nexus or I_T_x nexus shall not be aborted. Previously established conditions, including MODE SELECT parameters, reservations, and extended contingent allegiance shall not be changed by the ABORT TAG message. 6.5.3. BUS DEVICE RESET The BUS DEVICE RESET message is sent from an initiator to direct a target to clear all I/O processes on that SCSI device. This message forces a reset condition to the selected SCSI device. The target shall disconnect following successful receipt of this message if this message is transferred using the MESSAGE OUT phase. The target shall create a unit attention condition for all initiators (see 6.13). 6.5.4. CLEAR QUEUE The CLEAR QUEUE message shall be implemented if tagged queuing is implemented and may be implemented if untagged queuing is implemented. The target shall disconnect following successful receipt of this message if the message is transferred using the MESSAGE OUT phase. The target shall perform an action equivalent to receiving a series of ABORT messages from each initiator. All I/O processes, from all initiators, 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. All pending status and data for that logical unit or target routine for all initiators 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 initiators 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 allegiance shall not be changed by the CLEAR QUEUE message. 6.5.5. COMMAND COMPLETE 92 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The COMMAND COMPLETE message is sent from a target to an initiator to indicate that the execution of an I/O process has completed and that valid status has been sent to the initiator. The I/O process may have completed successfully or unsuccessfully as indicated in the status. After successfully sending this message, the target shall disconnect when using the MESSAGE IN phase. The target shall consider the message transmission to be successful, during the MESSAGE IN phase, when it detects the negation of ACK for the COMMAND COMPLETE message with the ATN signal false. When using information packets with a serial bus, the target shall consider the message transmission to be successful when an acknowledgement information packet is received for the information packet containing the COMMAND COMPLETE MESSAGE, 6.5.6. DISCONNECT The DISCONNECT message is sent from a target using the MESSAGE IN phase to inform an initiator that the present connection is going to be broken (the target plans to disconnect by releasing the BSY signal), but that a later reconnect will be required in order to complete the current I/O process. This message shall not cause the initiator to save the data pointer. After successfully sending this message, the target shall disconnect. The target shall consider the message transmission to be successful when it detects the negation of the ACK signal for the DISCONNECT message with the ATN signal false. Targets which break data transfers into bursts using multiple connections shall end each successful connection (except possibly the last) with a SAVE DATA POINTER - DISCONNECT message sequence. This message may also be sent from an initiator to a target using the MESSAGE OUT phase to instruct the target to disconnect from the SCSI bus. If this option is supported in the target, and after the DISCONNECT message is received, the target shall switch to MESSAGE IN phase, send the DISCONNECT message to the initiator (possibly preceded by SAVE DATA POINTER message), and then disconnect by releasing BSY. After releasing the BSY signal, the target shall not participate in another ARBITRATION phase for at least a disconnection delay. (???? GRS) If this option is not supported, or the initiator has identified the I/O process with disconnection disallowed, or the target cannot disconnect at the time when it receives the DISCONNECT message from the initiator, the target shall respond by sending a MESSAGE REJECT message to the initiator. 6.5.7. EXTENDED MESSAGE REJECT This message shall be supported if information packeta are supported. This message shall not be transmitted using the message phase. The EXTENDED MESSAGE REJECT message (Table 6-v) is sent from either the initiator or target 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. 93 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 For parallel interfaces, to indicate its intentions of sending an information packet containing this message, the initiator shall assert the ATN signal. The target enters the NEXUS TRANSFER OUT phase at the next appropriate point in a data phase or at the end of the current nexus transfer phase. If the target receives this message in an information packet under any other circumstance, it shall reject this message. When a target sends this message, it shall use to NEXUS TRANSFER IN phase and send an information packet containing this message. The content of the extended message identifies the message group and the message byte within the group. In addition, the message also indicates whether the reason for the rejection. This provides a logical interlock so that the sender of the message can determine which message byte is in error. Table 6-v: EXTENDED MESSAGE REJECT Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | 04h | Extended message length | ----------|----------|-------------------------------------------------------| 2 | 04h | Extended message code | ----------|----------|-------------------------------------------------------| 3 | x | ILE Position | ----------|----------|-------------------------------------------------------| 4 | x | Position in ILE | ----------|----------|-------------------------------------------------------| 5 | x | Reject Reason Code | ============================================================================== The ILE Position is the position of the message interface logical element within the information packet containing the error. The ILE Position is a value in the range of 1 to 255. There may be more than one message interface logical element in one information packet. The Position in ILE is the byte position of the byte in error within the element bytes. 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. 6.5.8. IDENTIFY 94 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The IDENTIFY message (Table 6-w) is sent by either the initiator or the target using the message phase to establish an I_T_L nexus or an I_T_R nexus. IMPLEMENTORS NOTE: Use of the IDENTIFY message to establish an I_T_R nexus allows connection to one of up to eight target routines or functions in the target itself. These target routines are expected to be used for maintenance and diagnostic purposes. Table 6-w: IDENTIFY Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 |Identify|DiscPriv| LUNTAR |Reserved|Reserved| LUNTRN | ============================================================================== The identify bit shall be set to one to specify that this is an IDENTIFY message. A disconnect privilege (DiscPriv) bit of one specifies that the initiator has granted the target the privilege of disconnecting. A DiscPriv bit of zero specifies that the target shall not disconnect. This bit is not defined and shall be set to zero when an IDENTIFY message is sent by a target. A logical unit target (LUNTAR) bit of zero specifies that the I/O process is directed to or from a logical unit. A LUNTAR bit of one specifies that the I/O process is directed to or from a target routine. The logical unit number target routine number (LUNTRN) field specifies a logical unit number if the LUNTAR bit is zero. The LUNTRN field specifies a target routine number if the LUNTAR bit is one. The response to an invalid value in the LUNTRN field is described in 6.10.3. Only the INQUIRY and REQUEST SENSE commands are valid for target routines. If a target receives any other command for a target routine, it shall return CHECK CONDITION status and shall set the sense key to ILLEGAL REQUEST. An IDENTIFY message is invalid if a reserved bit is set to one or if the LUNTAR bit is set to one and the target does not implement target routines. A device may respond to an invalid IDENTIFY message by immediately sending a MESSAGE REJECT message or by returning CHECK CONDITION status. If a CHECK CONDITION status is returned, the sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID BITS IN IDENTIFY MESSAGE FIELD. Only one logical unit number or target routine number shall be identified per I/O process. The initiator may send one or more IDENTIFY messages during a connection. A second IDENTIFY message with a different value in either the LUNTAR bit or LUNTRN field shall not be issued before disconnect; if a target receives a second IDENTIFY message with a different value in either of these fields, it shall disconnect (see unexpected disconnect, 5.1.1). Thus an initiator may change the DiscPriv bit, but may not attempt to switch to 95 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 another I/O process. (See the DTDC field of the disconnect-reconnect page (7.3.3.2) for additional controls over disconnection.) An implied RESTORE POINTERS message shall be performed by the initiator prior to the assertion of the ACK signal on the next phase for an inbound IDENTIFY message sent during reconnection. 6.5.9. IGNORE WIDE RESIDUE Table 6-x: IGNORE WIDE RESIDUE Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (23h) | -----|-----------------------------------------------------------------------| 1 | Ignore | ============================================================================== The IGNORE WIDE RESIDUE message (Table 6-x) shall be sent by a target or an initiator to indicate that the number of valid bytes sent during the last REQ/ACK handshake and REQB/ACKB handshake of a data phase or nexus transfer phase is less than the negotiated transfer width. The ignore field indicates the number of invalid data bytes transferred. This message shall be sent immediately following the DATA IN phase by the target and prior to any other messages. The initiator shall indicate its intent to send this message by asserting the ATN signal before asserting ACK for the last transfer of a REQ/ACK-REQB/ACKB handshake of a data or nexus transfer phase. The ignore field is defined as follows: Invalid Data Bits Ignore 32-bit Transfers 16-bit Transfers ---------- ---------------- ---------------- 00h Reserved Reserved 01h DB(31-24) DB(15-8) 02h DB(31-16) Reserved 03h DB(31-8) Reserved 04h to FFh Reserved Reserved Even though a byte is invalid its corresponding parity bit shall be valid for the value transferred. For 16-bit transfers, DB(31-16) are always invalid and the corresponding parity bits are also invalid. 6.5.10. INFORMATION PACKET IDENTIFY This message shall be supported if information packets are supported. This message shall not be transmitted using the message phase. The INFORMATION PACKET IDENTIFY message (Table 6-y) is sent by either the initiator or the target to establish an H_C_L nexus, an H_C_R nexus, an I_T_L nexus or an I_T_R nexus. The message is also used to specify certain options about the 96 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 connections for a nexus. In configurations which support multiple path operations, this message is used to permit or prevent the two types of nexus which are possible. In addition, the message is used to enable the target controller to execute supervisor commands. Table 6-y: INFORMATION PACKET IDENTIFY Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | 08h | Extended message length | ----------|----------|-------------------------------------------------------| 2 | 05h | Extended message code | ----------|----------|-------------------------------------------------------| 3 | x | Connection Conditions (See Table 6-z) | ----------|----------|-------------------------------------------------------| 4 | x | LUNTRNID (See Table 6-1a) | ----------|----------|-------------------------------------------------------| 5 | x | Initiator SCSI Address | ----------|----------|-------------------------------------------------------| 6 | x | Target SCSI Address | ----------|----------|-------------------------------------------------------| 7 | 00h | Reserved | ============================================================================== Table 6-z: Connection Conditions ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 |DiscPriv| LUNTAR |SuspMpth|EnbSpvr |Reserved|Reserved|Reserved|Reserved| ============================================================================== A disconnect privilege (DiscPriv) bit of one specifies that the the target has been granted the privilege of disconnecting. A DiscPriv bit of zero specifies that the target shall not disconnect. When sent by a target during a reconnection, the value of this bit shall be the same as the most recent value received for this I/O process. For serial bus implementations, the value shall always set this bit to 1. A logical unit target (LUNTAR) bit of zero specifies that the I/O process is directed to or from a logical unit. A LUNTAR bit of one specifies that the I/O process is directed to or from a target routine. The logical unit or target routine is identified in the LUNTRNID field. When sent by a target during a reconnection, the value of this bit shall be the same as the most recent value received for this I/O process. A suspend multiple path (SuspMpth) bit of one specifies that the initiator requires the target controller to override multiple path operation. The effect is to form an H_I_T_C nexus from the H_C nexus. The multiple path 97 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 operation is interpreted for each nexus. The setting has no effect on any other active or queued I/O process in the target controller. A enable supervisor command (EnbSpvr) bit of one specifies that the initiator has granted the target the privilege of executing any valid supervisor command received during the I/O process in which the enable supervisor command bit is set to 1. If the bit is set to zero and a supervisor command is present in the I/O process, the target controller shall terminate the I/O process with CHECK CONDITION status 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. (Section 7 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. Table 6-1a: LUNTRNID ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | LUNTRNID | ============================================================================== The logical unit number target routine number (LUNTRNID) field specifies a logical unit number if the LUNTAR bit is zero. The LUNTRNID field specifies a target routine number if the LUNTAR bit is one. The response to an invalid value in the LUNTRNID field is described in 6.10.3. The Initiator SCSI Address is a number in the range of 0 to 15 which specifies the SCSI Address assigned to the SCSI device initiating an I/O process. Values 16 through 255 are reserved. The Target SCSI Address is a number in the range of 0 to 15 which specifies the SCSI Address assigned to the SCSI device selected to perform an I/O process. Values 16 through 255 are reserved. An INFORMATION PACKET IDENTIFY message is invalid if a reserved bit is set to one, or if the LUNTAR bit is set to one and the target does not implement target routines, or on any subsequent connection after the connect for either the initiator or target to change the value of the SuspMpth or EnbSpvr bits. A target may respond to an invalid INFORMATION PACKET IDENTIFY message by sending an EXTENDED MESSAGE REJECT message in an information packet or by returning CHECK CONDITION status and sense data in an information packet. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID BITS IN INFORMATION PACKET IDENTIFY MESSAGE FIELD. (Section 7 update required. GRS) An initiator shall respond with an appropriate abort message in an information packet. The target aborts the I/O process and prepares sense data. Only one logical unit number or target routine number shall be identified per information packet. A second INFORMATION PACKET IDENTIFY message with a different value in either the LUNTAR bit or LUNTRNID field shall not be 98 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 issued within the same information packet. If a target receives a second INFORMATION PACKET IDENTIFY message in one information packet with a different value in either of these fields, it shall not process the content of an information packet beyond the point of the invalid INFORMATION PACKET IDENTIFY message. Thus, for parallel interfaces, an initiator may change the DiscPriv bit, but may not attempt to switch to another I/O process. (See the DTDC field of the disconnect-reconnect page (7.3.3.2) for additional controls over disconnection.) Different information packets during a connection may have different logical units and/or target routines identified. An implied RESTORE POINTERS message shall be performed by the initiator for each inbound information packet. 6.5.11. INITIATE RECOVERY A target that supports extended contingent allegiance shall inform the initiator it is entering this condition by sending an INITIATE RECOVERY message immediately following a CHECK CONDITION or COMMAND TERMINATED status. The extended contingent allegiance condition remains in effect until terminated as described in 6.12. If an asynchronous event occurs, the target may enter an extended contingent allegiance condition by becoming a temporary initiator and sending the INITIATE RECOVERY message following the IDENTIFY message or INFORMATION PACKET IDENTIFY message, as appropriate, followed by any queue tag message and then the SEND command that is used to perform asynchronous event notification (see 6.10.7). The successful transmission of this message establishes the extended contingent allegiance condition which remains in effect until terminated as described in 6.12. If the target notifies multiple initiators 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 initiators (e.g., a buffered mode setting of 2 for sequential access devices). A MESSAGE REJECT response to an INITIATE RECOVERY message indicates that an extended contingent allegiance condition shall not be established. The enabled or disabled state of an extended contingent allegiance (see the DQue bit of the control mode page, 7.3.3.1) is not changed by the rejection of an INITIATE RECOVERY message. 6.5.12. INITIATOR DETECTED ERROR The INITIATOR DETECTED ERROR message is sent from an initiator to inform a target that an error has occurred that does not preclude the target from retrying the operation. The source of the error may either be related to previous activities on the SCSI bus or may be internal to the initiator and unrelated to any previous SCSI bus activity. Although present pointer integrity is not assured, a RESTORE POINTERS message or a disconnect followed by a reconnect, shall cause the pointers to be restored to their defined 99 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 prior state. See the INVALID BUS PHASE DETECTED, MESSAGE PARITY ERROR, PARITY ERROR, and RESEND LAST INFORMATION PACKET messages for specific conditions which shall be reported using these messages. 6.5.13. INVALID BUS PHASE DETECTED Table 6-1b: INVALID BUS PHASE DETECTED Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (25h) | -----|-----------------------------------------------------------------------| 1 | RESERVED | Msg | C/D | I/O | ============================================================================== The INVALID BUS PHASE DETECTED message is sent from an initiator to inform a target that an illegal or reserved bus phase was detected. Table 6-1b defines the format for the INVALID BUS PHASE DETECTED message. If a SCSI device does not implement INVALID BUS PHASE DETECTED message, it shall respond with a MESSAGE REJECT 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. 6.5.14. INVALID INFORMATION PACKET This message shall be supported if information packets are supported. This message shall not be transmitted using the message phase. The INVALID INFORMATION PACKET message (Table 6-1c) is sent from either the initiator or target in an information packet to indicate that all or a portion of the last information packet transferred was invalid. The format of the information packet does not conform to the rules for information packet construction. In order to indicate its intentions of sending an information packet containing this message, the initiator shall cause the attention condition. The target enters the NEXUS TRANSFER OUT phase at the end of the current nexus transfer phase. If the target receives this message in an information packet under any other circumstance, it shall reject this message. 100 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 When a target sends this message, it shall change to NEXUS TRANSFER IN phase and send an information packet containing this message the initiator. Table 6-1c: INVALID INFORMATION PACKET Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | 04h | Extended message length | ----------|----------|-------------------------------------------------------| 2 | 06h | Extended message code | ----------|----------|-------------------------------------------------------| 3 | x | ILE Number | ----------|----------|-------------------------------------------------------| 4 | x | Reason Code | ============================================================================== The ILE Number is the position of the interface logical element group within the information packet containing the error. The ILE number is a value in the range of 1 to 255. There may be more than one message interface logical element in each information packet. The Reason Code identifies the reason for sending the message. A code of 00h indicates the first interface logical element is not a message type. A code of 01h indicates that the interface logical element type in a descriptor is invalid. Reason code 00h is used to specifically identify an error in the first interface logical element. A code of 02h indicates that the interface logical element length field is invalid. Codes 03h-FFh are reserved. 6.5.15. LINKED COMMAND COMPLETE The LINKED COMMAND COMPLETE message is sent from a target to an initiator to indicate that the execution of a linked command has completed and that status has been sent. The initiator shall then set the pointers to the initial state for the next linked command. 6.5.16. LINKED COMMAND COMPLETE (WITH FLAG) The LINKED COMMAND COMPLETE (WITH FLAG) message is sent from a target to an initiator 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 initiator shall then set the pointers to the initial state of the next linked command. Typically this message would be used to cause an interrupt in the initiator between two linked commands. 6.5.17. MESSAGE PARITY ERROR 101 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 This message is retained for backward compatibility with SCSI-2. SCSI-3 implementations of initiators and targets when transferring information packets shall use the PARITY ERROR message. The MESSAGE PARITY ERROR message is sent by an initiator or a target to indicate that a message byte it received had a parity error. The procedures outlined below replace those described in Section 5.1.9.2 with a symmetrical procedure for both initiators and targets. 6.5.17.1 Initiator Detected Parity Errors In order to indicate its intentions of sending this message, the initiator shall assert the ATN signal prior to its release of the ACK signal for the REQ/ACK handshake of the message byte that has the parity error. This provides an interlock so that the target can determine, before the end of the MESSAGE IN phase, that the messages must be kept until the ATN signal has been responded to. If the target receives this message under any other circumstance, it shall signal a catastrophic error condition by switching to the MESSAGE IN phase and sending the MESSAGE REJECT message. The target shall return to the MESSAGE IN phase before switching to some other phase, after receiving the MESSAGE PARITY ERROR message, and the target shall resend the entire set of messages that had at least one parity error. 6.5.17.2 Target Detected Parity Errors In order to indicate its intentions of sending this message, the target shall switch to the MESSAGE IN phase after the ATN signal has gone false for the last REQ/ACK handshake of the MESSAGE OUT phase where the parity error was detected, but before changing to any other phase. This provides an interlock so that the initiator can determine before it loses access to the messages that they must be kept until the MESSAGE IN phase has been responded to. If the initiator receives this message under any other circumstance, it shall signal a catastrophic error condition by asserting the ATN signal and transferring a MESSAGE REJECT message. The target shall return to the MESSAGE OUT phase before switching to some other phase, after sending the MESSAGE PARITY ERROR message, and the initiator shall resend the entire set of messages that had at least one parity error. 6.5.18. MESSAGE REJECT This message is retained for backward compatibility with SCSI-2. SCSI-3 implementations of initiators and targets when transferring information packets shall use the EXTENDED MESSAGE REJECT message. The MESSAGE REJECT message is sent from either the initiator or target using the message phases to indicate that the last message or message byte it received was inappropriate or has not been implemented. In order to indicate its intentions of sending this message, the initiator shall assert the ATN signal prior to its release of the ACK signal for the 102 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 REQ/ACK handshake of the message byte that is to be rejected. If the target receives this message under any other circumstance, it shall reject this message. When a target sends this message, it shall change to MESSAGE IN phase and send this message prior to requesting additional message bytes from the initiator. This provides an interlock so that the initiator can determine which message byte is rejected. After a target sends a MESSAGE REJECT message and if the ATN signal is still asserted, then it shall return to the MESSAGE OUT phase. The subsequent MESSAGE OUT phase shall begin with the first byte of a message. 6.5.19. MODIFY DATA POINTER Message Table 6-1d: MODIFY DATA POINTER ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 05h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 00h | MODIFY DATA POINTER code | -----|---------|-------------------------------------------------------------| 3 | x | Argument (Most Significant Byte) | -----|---------|-------------------------------------------------------------| 4 | x | Argument | -----|---------|-------------------------------------------------------------| 5 | x | Argument | -----|---------|-------------------------------------------------------------| 6 | x | Argument (Least Significant Byte) | ============================================================================== The MODIFY DATA POINTER message (Table 6-1d) is sent from the target to the initiator and requests that the signed argument be added (two's complement) to the value of the current data pointer. This message shall be used with information packets instead of the SAVE DATA POINTER, RESTORE POINTERS, and DISCONNECT messages to control or adjust the data pointer value for a current I/O process. 6.5.20. NO OPERATION The NO OPERATION message is sent from an initiator in response to a target's request for a message using the MESSAGE OUT phase when the initiator does not currently have any other valid message to send. For example, if the target does not respond to the attention condition until a later phase and at that time the original message is no longer valid the initiator may send the NO OPERATION message when the target enters the MESSAGE OUT phase. 103 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 6.5.21. PARITY ERROR Table 6-1e: PARITY ERROR Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (24h) | -----|-----------------------------------------------------------------------| 1 | RESERVED | Msg | C/D | I/O | ============================================================================== Table 6-1e defines the format for the parity error message. If a SCSI device does not implement PARITY ERROR message, it shall respond with a MESSAGE REJECT 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 in which the parity error was detected. 6.5.21.1. Initiator Detected Parity Errors for MESSAGE Phase In order to indicate its intentions of sending this message, the initiator shall assert the ATN signal prior to its release of the ACK signal for the REQ/ACK handshake of the message byte that has the parity error. This provides an interlock so that the target can determine, before the end of the MESSAGE IN phase, that the messages must be kept until the ATN signal has been responded to. If the target receives this message under any other circumstance, it shall signal a catastrophic error condition by switching to the MESSAGE IN phase and sending the MESSAGE REJECT message. The target shall return to the MESSAGE IN phase before switching to some other phase, after receiving the PARITY ERROR message, and the target shall resend the entire set of messages that had at least one parity error. 6.5.21.2. Target Detected Parity Errors for MESSAGE Phase In order to indicate its intentions of sending this message, the target shall switch to the MESSAGE IN phase after the ATN signal has gone false for the last REQ/ACK handshake of the MESSAGE OUT phase where the parity error was detected, but before changing to any other phase. This provides an interlock so that the initiator can determine before it loses access to the messages that they must be kept until the MESSAGE IN phase has been responded to. If the initiator receives this message under any other circumstance, it 104 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 shall signal a catastrophic error condition by asserting the ATN signal and transferring a MESSAGE REJECT message. The target shall return to the MESSAGE OUT phase before switching to some other phase, after sending the PARITY ERROR message, and the initiator shall resend the entire set of messages that had at least one parity error. 6.5.22. Queue Tag Messages Table 6-1f: Queue Tag Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (20h or 21h or 22h) | -----|-----------------------------------------------------------------------| 1 | Queue Tag | ============================================================================== Table 6-1f defines the format for the queue tag messages. If the target implements tagged queuing, all of the queue tag messages are mandatory: HEAD OF QUEUE TAG, ORDERED QUEUE TAG, and SIMPLE QUEUE TAG. Tagged queuing is only defined for logical units, not target routines. If a target does not implement tagged queuing and a queue tag message is received or if a queue tag message is received for a target routine, it shall respond with a MESSAGE REJECT message and accept the I/O process as if it were untagged. The queue tag messages are used to specify an identifier, called a queue tag, for an I/O process which establishes an H_C_L_Q nexus or an I_T_L_Q nexus. The queue tag field is an 8-bit unsigned integer assigned by the initiator during an initial connection. The queue tag for every I/O process for each should be unique. If the target receives a queue tag that is currently in use, then it shall respond as defined in 6.10.2. A queue tag becomes available for re-assignment when the I/O process ends. The numeric value of a queue tag has no effect on the order of execution. IMPLEMENTORS NOTE: For each logical unit on each target, each initiator has up to 256 queue tags to assign to I/O processes. Thus a target with eight logical units could have up to 14336 I/O processes concurrently in existence if there were seven initiators on the bus. Whenever an initiator connects to a target, the appropriate queue tag message shall be sent immediately following the IDENTIFY message and within the same message interface logical element or MESSAGE OUT phase to establish the H_C_L_Q nexus or I_T_L_Q nexus for the I/O process. Only one H_C_L_Q nexus or I_T_L_Q nexus may be established during a connection. If a queue tag message is not sent, then only an H_C_L nexus or I_T_x nexus is established for the I/O process (untagged command). 105 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Whenever a target reconnects to an initiator to continue a tagged I/O process, the SIMPLE QUEUE TAG message shall be sent immediately following the IDENTIFY message and within the same MESSAGE IN phase to revive the H_C_L_Q nexus or I_T_L_Q nexus for the I/O process. Only one H_C_L_Q nexus or I_T_L_Q nexus may be revived during a reconnection. If the SIMPLE QUEUE TAG message is not sent, then only an H_C_L nexus or an I_T_x nexus is revived for the I/O process (untagged command). If a target attempts to reconnect using an invalid queue tag, then the initiator should respond with an ABORT TAG message. 6.5.22.1. HEAD OF QUEUE TAG The HEAD OF QUEUE TAG message specifies that the I/O process be placed first in that logical unit's command queue. An I/O process already being executed by the target shall not be preempted. A subsequent I/O process received with a HEAD OF QUEUE TAG message shall be placed at the head of the command queue for execution in last-in, first-out order. 6.5.22.2. ORDERED QUEUE TAG The ORDERED QUEUE TAG message specifies that the I/O process be placed in that logical unit's command queue for execution in the order received. All queued I/O processes for the logical unit received prior to this I/O process shall be executed before this I/O process is executed. All queued I/O processes received after this I/O process shall be executed after this I/O process, except for I/O processes received with a HEAD OF QUEUE TAG message. 6.5.22.3. SIMPLE QUEUE TAG The SIMPLE QUEUE TAG message specifies that the I/O process be placed in that logical unit's command queue. The order of execution is described in 6.14. 6.5.23. RELEASE RECOVERY The RELEASE RECOVERY message is sent from an initiator to a target to terminate an extended contingent allegiance condition previously established by an INITIATE RECOVERY message. This message shall be sent immediately following the IDENTIFY message in the same MESSAGE OUT phase or interface logical element in an information packet. The extended contingent allegiance condition ends upon successful receipt of the RELEASE RECOVERY message. The target shall discconnect following successful receipt of this message using the MESSAGE OUT phase. If a RELEASE RECOVERY message is received by a target that implements extended contingent allegiance when no extended contingent allegiance condition is active, the message shall not be rejected and the target shall disconnect. 6.5.24. RESEND PREVIOUS INFORMATION PACKET 106 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1g: Resend Previous Information Packet Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (26h) | -----|-----------------------------------------------------------------------| 1 | Previous Packet number | ============================================================================== This message shall be supported if the nexus transfer phase is supported. This message shall not be transmitted using the MESSAGE phase. The RESEND PREVIOUS INFORMATION PACKET message is sent by an initiator or a target to indicate that a previous information packet must be resent. The synchronous packet transfer request negotiation has produced an agreement on 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 represent 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 (6.5.28). 6.5.25. RESTORE POINTERS The RESTORE POINTERS message is sent from a target using the MESSAGE IN phase to direct the initiator to copy the most recently saved command, data, and status pointers for the I/O process to the corresponding active pointers. (See 6.1 for a definition of pointers.) The command and status pointers shall be restored to the beginning of the current command and status areas. The data pointer shall be restored to the value at the beginning of the data area in the absence of a SAVE DATA POINTER message or to the value at the point at which the last SAVE DATA POINTER message occurred for that nexus. This message shall not be sent using the NEXUS TRANSFER IN phase. 6.5.26. SAVE DATA POINTER The SAVE DATA POINTER message is sent from a target using a MESSAGE IN phase to direct the initiator to copy the active data pointer to the saved data pointer for the current I/O process. (See 6.1 for a definition of pointers.) This message shall not be sent using the NEXUS TRANSFER IN phase. 6.5.27. SYNCHRONOUS DATA TRANSFER REQUEST Message 107 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1h: SYNCHRONOUS DATA TRANSFER REQUEST ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 03h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 01h | SYNCHRONOUS DATA TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | m | Transfer period (m times 4 nanoseconds) | -----|---------|-------------------------------------------------------------| 4 | x | REQ/ACK offset | ============================================================================== A SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) message (Table 6-1h) exchange shall be initiated by an SCSI device whenever a previously-arranged data transfer agreement may have become invalid. The agreement becomes invalid after any condition which may leave the data transfer agreement in an indeterminate state such as: (1) after a hard reset condition (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SCSI device may initiate an SDTR message exchange whenever it is appropriate to negotiate a new data transfer agreement (either synchronous or asynchronous). SCSI devices that are capable of synchronous data transfers shall not respond to an SDTR message with a MESSAGE REJECT 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 data phases. The transfer period is the minimum time allowed between leading edges of successive REQ pulses and of successive ACK pulses to meet the device requirements for successful reception of data. The REQ/ACK offset is the maximum number of REQ pulses allowed to be outstanding before the leading edge of its corresponding ACK pulse is received at the target. 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 108 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 requires a larger transfer period, a smaller REQ/ACK offset, or both in order 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 as follows: 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) MESSAGE REJECT message Asynchronous transfer If the initiator recognizes that negotiation is required, it asserts the ATN signal and sends a SDTR message to begin the negotiating process. After successfully completing the MESSAGE OUT phase, the target shall respond with the proper SDTR message. If an abnormal condition prevents the target from returning an appropriate response, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. Following target response (1) above, the implied agreement for synchronous operation shall be considered to be negated by both the initiator and the target if the initiator asserts the ATN signal and the first message out is either MESSAGE PARITY ERROR or MESSAGE REJECT. In this case, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. For the MESSAGE PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of the pair of messages is successfully accomplished. After a vendor-specific number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY ERROR message, it shall terminate the retry activity. This may be done either by changing to any other information transfer phase and transferring at least one byte of information or by disconnecting (see 5.1.1). The initiator 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. If the target recognizes that negotiation is required, it sends an SDTR message to the initiator. Prior to releasing the ACK signal on the last byte of the SDTR message from the target, the initiator shall assert the ATN signal and respond with its SDTR message or with a MESSAGE REJECT message. If an abnormal condition prevents the initiator from returning an appropriate response, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. Following an initiator's responding SDTR message, an implied agreement for synchronous operation shall not be considered to exist until the target 109 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 leaves the MESSAGE OUT phase, indicating that the target has accepted the negotiation. After a vendor-specific number of retry attempts (greater than zero), if the target has not received the initiator's responding SDTR message, it shall disconect without any further information transfer attempt (see 5.1.1). This indicates that a catastrophic error condition has occurred. Both devices shall go to asynchronous data transfer mode for data transfers between the two devices. If, following an initiator's responding SDTR message, the target shifts to MESSAGE IN phase and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be negated and both devices shall go to asynchronous data transfer mode for data transfers between the two devices. For initiators and targets using information packets, the appropriately formatted messages are sent in information packets. The logical outcome is the same. 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 SCSI 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. IMPLEMENTORS NOTES: (1) Re-negotiation at every selection is not recommended, since a significant performance impact is likely. (2) Due to historical problems with early initiating controllers that could not accept an SDTR message, some targets may not initiate synchronous negotiation after a power cycle as required by this standard. Initiating controllers that support synchronous mode may avoid the ensuing failure modes when the target is independently power cycled by initiating a synchronous negotiation on each REQUEST SENSE and INQUIRY command. 6.5.28. SYNCHRONOUS PACKET TRANSFER REQUEST Message Table 6-1i. SYNCHRONOUS PACKET TRANSFER REQUEST ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 03h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 07h | SYNCHRONOUS PACKET TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | 00h | Reserved | -----|---------|-------------------------------------------------------------| 4 | m | Packet Offset count | ============================================================================== 110 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 A SYNCHRONOUS PACKET TRANSFER REQUEST (SPTR) message (Table 6-1i) exchange shall be initiated by an SCSI device whenever a previously arranged packet transfer agreement may have become invalid. This message shall be implemented if information packets are implemented. This message shall not be transmitted using the MESSAGE phase. Each SCSI device shall be able to retain at minimum one information packet per I/O process for retransmission (i.e., the last information packet successfully trtansferred in each direction). In the absence of an explicit agreement for value larger than one, the implied agreement shall be 1 for both initiating 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 initiating controller or target controller declares that it can retain at maximum or has agreed upon with another SCSI 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 POINTER message, there may be an additional requirement to retain additional information packets. The synchronous packet transfer agreement becomes invalid after any condition which may leave the packet transfer agreement in an indeterminate state such as: (1) after a hard reset condition (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SCSI 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. 111 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Each device, when transferring information packets, shall retain the number of information packets for retransmitting, as agreed upon in the most recent SPTR exchange or one, whichever is larger. 6.5.29. TERMINATE I/O PROCESS The TERMINATE I/O PROCESS message is sent from the initiator to the target to advise the target to terminate the current I/O process without corrupting the medium. Upon successful receipt of this message the target shall terminate the current I/O process as soon as possible and return COMMAND 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 TERMINATE I/O PROCESS message shall not affect pending status, data, and commands for other queued or executing I/O processes. However, continued execution and status of other I/O processes queued for the H_C_x nexus or I_T_x nexus may be affected by the queue error recovery option specified in the control mode page (see 7.3.3.1). 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 information field shall be set as follows: (1) If the command descriptor block specifies an allocation length or parameter list length in bytes, the information 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 (see 7.2.14). If the I/O process being terminated has no data transfer associated with it the target shall set the valid bit in the sense data to zero and terminate the I/O process with COMMAND 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 for an I/O process the target shall ignore the TERMINATE I/O PROCESS message and terminate the I/O process with the appropriate error status and sense data for the error condition. If the target 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 shall ignore the TERMINATE I/O PROCESS message and terminate the I/O process in the normal manner. If the target 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 or an I_T_x nexus that does not have an active or queued I/O process, the target shall set the valid bit in the sense data to zero and terminate the I/O process with COMMAND 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 current I/O process is in the command queue (an H_C_x nexus or I_T_x nexus for untagged queuing or an H_C_L_Q nexus or I_T_L_Q nexus for tagged 112 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 queuing) and has not started execution, the target shall either terminate the I/O process immediately or disconnect and wait until the command is at the head of the queue (started executing) then terminate the I/O process. In either case, the target shall terminate the I/O process with COMMAND 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. If the target does not support this message or is unable to stop the current I/O process for the H_C_x nexus or I_T_x nexus, it shall respond by sending a MESSAGE REJECT message to the initiator and continuing the I/O process in a normal manner. IMPLEMENTORS NOTE: The TERMINATE I/O PROCESS message provides a means for the initiator to request the target to reduce the transfer length of the current command to the amount that has already been transferred. The initiator can use the sense data to determine the actual number of bytes or blocks that have been transferred. This message is normally used by the initiator to stop a lengthy read, write, or verify operation when a higher priority command is available to be executed. It is up to the initiator to complete the terminated command at a later time, if required. 6.5.30. WIDE DATA TRANSFER REQUEST Message Table 6-1j: WIDE DATA TRANSFER MESSAGE ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 02h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 03h | WIDE DATA TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | m | Transfer Width (2**m bytes) | ============================================================================== A WIDE DATA TRANSFER REQUEST (WDTR) message (Table 6-1j) exchange shall be initiated by an SCSI device whenever a previously-arranged transfer width agreement may have become invalid. The agreement becomes invalid after any condition which may leave the data transfer agreement in an indeterminate state such as: (1) after a hard reset condition (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SCSI device may initiate an WDTR message exchange whenever it is appropriate to negotiate a new transfer width agreement. SCSI devices 113 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 that are capable of wide data transfers (greater than eight bits) shall not respond to an WDTR message with a MESSAGE REJECT message. The WDTR message exchange establishes an agreement between two SCSI devices on the width of the data path to be used for DATA phase and nexus information transfers between the two devices. All other information transfer phases shall use an eight-bit data path. If an SCSI device implements both wide data transfer option and synchronous data transfer option, then it shall negotiate the wide data transfer agreement prior to negotiating the synchronous data transfer agreement. If a synchronous data transfer agreement is in effect, then an SCSI device that accepts a WDTR message shall reset the synchronous agreement to asynchronous mode. The transfer width that is established applies to all logical units on both SCSI devices. Valid transfer widths are 8 bits (m = 00h), 16 bits (m = 01h), and 32 bits (m = 02h). Values of m greater than 02h are reserved. The originating SCSI device (the SCSI device that sends the first of the pair of WDTR messages) sets its transfer width value to the maximum data path width it elects to accommodate. If the responding SCSI device can also accommodate this transfer width, it returns the same value in its WDTR message. If it requires a smaller transfer width, it substitutes the smaller value in its WDTR message. The successful completion of an exchange of WDTR messages implies an agreement as follows: Responding Device WDTR Response Implied Agreement -------------------------------- ------------------------------------------- (1) Non-zero transfer width Each device transmits and receives data with a transfer width equal to the responding SCSI device's transfer width. (2) Transfer width equal to zero Eight-bit Data Transfer (3) MESSAGE REJECT message Eight-bit Data Transfer If the initiator recognizes that negotiation is required, it sends a WDTR message to begin the negotiating process. After receiving the message, the target shall respond with the proper WDTR message. If an abnormal condition prevents the target from returning an appropriate response, both devices shall go to eight-bit data transfer mode for data transfers between the two devices. Following target response (1) above, the implied agreement for wide data transfers shall be considered to be negated by both the initiator and the target if the initiator asserts ATN and the first message out is either MESSAGE PARITY ERROR or MESSAGE REJECT. In this case, both devices shall go to eight-bit data transfer mode for data transfers between the two devices. For the MESSAGE PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of the pair of messages is successfully accomplished. After a vendor-specific number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY ERROR message, it shall 114 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 terminate the retry activity. This may be done either by changing to any other information transfer phase and transferring at least one byte of information or by disconnecting (see 5.1.1). The initiator shall accept such action as aborting the negotiation, and both devices shall go to eight-bit data transfer mode for data transfers between the two devices. If the target recognizes that negotiation is required, it sends a WDTR message to the initiator. Prior to releasing the ACK signal on the last byte of the WDTR message from the target, the initiator shall assert the ATN signal and respond with its WDTR message or with a MESSAGE REJECT message. If an abnormal condition prevents the initiator from returning an appropriate response, both devices shall go to eight-bit data transfer mode for data transfers between the two devices. Following an initiator's responding WDTR message, an implied agreement for wide data transfer operation shall not be considered to exist until the target leaves the current phase, indicating that the target has accepted the negotiation. After a vendor-specific number of retry attempts (greater than zero), if the target has not received the initiator's responding WDTR message, it shall disconnect without any further information transfer attempt (see 5.1.1). This indicates that a catastrophic error condition has occurred. Both devices shall go to eight-bit data transfer mode for data transfers between the two devices. If, following an initiator's responding WDTR message, the target shifts to MESSAGE IN phase and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be negated and both devices shall go to eight-bit data transfer mode for data transfers between the two devices. For initiators and targets using information packets, the appropriately formatted messages are sent in information packets. The logical outcome is the same. The implied transfer width 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 SCSI devices elects to modify the agreement. The default data transfer width is eight-bit 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. 6.6. Commands and Status This section defines the SCSI command structure, the status structure, status content, the contingent allegiance condition, the extended contingent allegiance condition, and the unit attention condition; gives information on processing and exception conditions, and command queueing; and provides several examples. (Update. GRS) By keeping to a minimum 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 architecture may be implemented, optional functions are noted. 115 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 A device class is defined as a group of devices that implement the mandatory commands and functions in Sections 5 through 7 and the mandatory commands and functions defined in one of the sections, 8 through 17. Multiple device class implementations are .... (??? GRS) A device type is defined as 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 commands and functions in Sections 5 through 7 and the mandatory commands and functions in the appropriate section for its device class. 6.6.1. Command Implementation Requirements The first byte of all SCSI commands shall contain an operation code as defined in this standard. All SCSI devices which implement target mode shall implement all commands with a mandatory operation code (see 6.6.3) and all mandatory functions within each command both in section 7 and in the appropriate section for their device class. 6.6.2. Reserved Reserved bits, fields, bytes, and code values are set aside for future standardization. Their use and interpretation may be specified by future extensions to this standard. A reserved bit, field, or byte shall be set to zero, or in accordance with a future extension to this standard. A target that receives a reserved bit, field, or byte that is not zero or receives a reserved code value shall terminate the command with CHECK CONDITION status and the sense key shall be set to ILLEGAL REQUEST. It shall also be acceptable for a target to interpret a bit, field, byte, or code value in accordance with a future extension to this standard. 6.6.3. Operation Code Types 116 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 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. 6.7. Command Descriptor Block A command is communicated by sending a command descriptor block to the target. For several commands, the command descriptor block is accompanied by command parameter data. See the specific commands for detailed information about which commands require command parameter data. Command parameter data is sent either during the DATA OUT phase when the COMMAND phase is used to send the command descriptor block or as an additional interface logical element in the same information packet as the command, in a separate information packet, or split across several information packets. (See 6.7.5.) The command descriptor block shall have the operation code as its first byte and a control byte as its last byte (6.6.1 and 6.7.7). A parameter is defined as the value of a field. For all commands, if there is an invalid parameter in the command descriptor block, or the command parameter data, the target controller shall terminate the command and the I/O process without altering the medium. 117 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1k: Typical Command Descriptor Block for Six-byte Commands ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code | -----|-----------------------------------------------------------------------| 1 | Reserved | (MSB) | -----|------------------------------ ---| 2 | Logical Block Address (if required) | -----|--- ---| 3 | (LSB) | -----|-----------------------------------------------------------------------| | Transfer Length (if required) | 4 | Command Parameter Data Length(if required) | | Command Response Data Length (if required) | -----|-----------------------------------------------------------------------| 5 | Control | ============================================================================== Table 6-1m: Typical Command Descriptor Block for Ten-byte Commands ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code | -----|-----------------------------------------------------------------------| 1 | Reserved | Reserved | -----|-----------------------------------------------------------------------| 2 | (MSB) | -----|--- ---| 3 | | -----|--- Logical Block Address (if required) ---| 4 | | -----|--- ---| 5 | (LSB) | -----|-----------------------------------------------------------------------| 6 | Reserved | -----|-----------------------------------------------------------------------| 7 | (MSB) Transfer Length (if required) | -----|--- Command Parameter Data Length(if required) ---| 8 | Command Response Data Length (if required) (LSB) | -----|-----------------------------------------------------------------------| 9 | Control | ============================================================================== 118 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1n: Typical Command Descriptor Block for Twelve-byte Commands ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code | -----|-----------------------------------------------------------------------| 1 | Reserved | Reserved | -----|-----------------------------------------------------------------------| 2 | (MSB) | -----|--- ---| 3 | | -----|--- Logical Block Address (if required) ---| 4 | | -----|--- ---| 5 | (LSB) | -----|-----------------------------------------------------------------------| 6 | (MSB) | -----|--- ---| 7 | Transfer Length (if required) | -----|--- Command Parameter Data Length(if required) ---| 8 | Command Response Data Length (if required) | -----|--- ---| 9 | (LSB) | -----|-----------------------------------------------------------------------| 10 | Reserved | -----|-----------------------------------------------------------------------| 11 | Control | ============================================================================== 6.7.1. Operation Code The operation code (Table 6-1o) 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 the subsequent Sections of this document. The group code is defined as follows: Group 0 - six-byte commands (see Table 6-1k) Group 1 - ten-byte commands (see Table 6-1m) Group 2 - ten-byte commands (see Table 6-1m) Group 3 - reserved Group 4 - reserved Group 5 - twelve-byte commands (see Table 6-1n) Group 6 - vendor specific Group 7 - vendor specific 119 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1o: Operation Code ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Group Code | Command Code | ============================================================================== 6.7.2. Logical Unit Number (Reclaimed Field, Byte 1, bits 7-5) The Logical Unit Number field was defined in all Command Descriptor Blocks through SCSI-2. The field function was replaced by a similar field in the mandatory IDENTIFY message in SCSI-2 to identify logical units and target routines. The field space is reclaimed in the CDB, and made reserved. The logical unit number is transferred in the IDENTIFY message (6.5.8) when information packets are not used to transfer the message. When an information packet is used, the logical unit number is transferred in the INFORMATION PACKET IDENTIFY message (6.5.10), which provides for extended addressing of logical units and target routines. 6.7.3. Logical Block Address The logical block address on logical units or within a partition shall begin with block zero and be contiguous up to the last logical block on that logical unit or within that partition. Not all device classes support logical block addressing. 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. 6.7.4. 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. 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 following descriptions and the individual command descriptions for further information. 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 number of blocks or bytes that shall be transferred. A value of zero indicates 256 blocks or bytes. 120 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 In commands that use multiple bytes for the transfer length, a transfer length of zero indicates that no data transfer shall take place. A value of one or greater indicates the maximum number of blocks or bytes that shall be transferred. Refer to the specific command descriptions for further information. 6.7.5. Command Parameter Data Length The command parameter data length field is used to specify the maximum number of bytes to be transferred by a target during the data phase after the command descriptor block has been transferred using the COMMAND phase. When the command descriptor block is transferred in an information packet, the command parameter data may be included as a subsequent interface logical element in the same information packet, a separate information packet, or split across multiple information packets. This field is typically used in command descriptor blocks for command parameter data that are sent to a target (e.g., mode parameters, diagnostic parameters, log parameters, etc.). A command parameter data length field of zero indicates that no data shall be transferred. This condition shall not be considered as an error. (Section 7+ CDBs may require changes. GRS) 6.7.6. Command Response Data Length The command response data length field specifies the maximum number of bytes that a target 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 initiator by a target. A command response data length of zero indicates that no data shall be transferred. This condition shall not be considered as an error. When using the data phase to transfer the command response data, the target shall terminate transfer when command response data length bytes have been transferred or when all available data have been transferred to the initiator, whichever is less. When the nexus transfer phase is used to transfer the command response data, the target may place all data in a single information packet, or split the command response data over multiple information packets. The total length of the data bytes shall not exceed the command responde data length specified in the command descriptor block. (Section 7+ CDBs may require changes. GRS) 6.7.7. Control Field The control field is the last byte of every command descriptor block. The control field is defined in Table 6-1p. 121 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1p: Control Field ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Vendor specific | Reserved | Flag | Link | ============================================================================== The flag bit specifies which message the target shall return to the initiator if the link bit is one and the command completes without error. Implementation of the flag bit is optional. 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 shall return CHECK CONDITION status. 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 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 shall send the LINKED COMMAND COMPLETE (WITH FLAG) message. The link bit is used to continue an I/O process across multiple commands. Implementation of the link bit is optional. A link bit of one indicates that the initiating controller requests a continuation of the I/O process using the target controller command queue for the I/O process, or request a new command upon successful completion of the current command if no commmand is queued. If the link bit is one, and if the command completes successfully, the target shall return INTERMEDIATE or INTERMEDIATE-CONDITION MET status and shall then send one of the two messages defined by the flag bit. If either of the link and flag bits are set to one, and the target does not implement linked commands, it shall return CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST. IMPLEMENTORS NOTE: The flag bit is typically used to cause an interrupt in the initiator between linked commands. 6.8. Status The status byte and status byte code are specified in Tables 6-1q and 6-1r, respectively. A status byte shall be sent from the target to the initiator at the completion of each command unless the command is terminated by one of the following events: (1) an ABORT message (2) an ABORT TAG message (3) a BUS DEVICE RESET message (4) a CLEAR QUEUE message (5) a hard reset condition (6) an unexpected disconnect (see 5.1.1) Status transfer occurs at the end of a command. In some cases, status transfer may occur prior to transferring the command descriptor block. 122 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1q: Status Byte ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Reserved | Status Byte Code |Reserved| ============================================================================== Table 6-1r: Status Byte Code ============================================================================== Bits of Status Byte ----------------------------- 7 6 5 4 3 2 1 0 Status ------------------------------------------------------------------------------ R R 0 0 0 0 0 R GOOD R R 0 0 0 0 1 R CHECK CONDITION R R 0 0 0 1 0 R CONDITION MET R R 0 0 1 0 0 R BUSY R R 0 1 0 0 0 R INTERMEDIATE R R 0 1 0 1 0 R INTERMEDIATE-CONDITION MET R R 0 1 1 0 0 R RESERVATION CONFLICT R R 1 0 0 0 1 R COMMAND TERMINATED R R 1 0 1 0 0 R QUEUE FULL All Other Codes Reserved ============================================================================== Key: R - Reserved bit The definition of the status byte codes is given below. GOOD. This status indicates that the target has successfully completed the command. CHECK CONDITION. This status indicates that a contingent allegiance condition has occurred (see 6.6). CONDITION MET. This status or INTERMEDIATE-CONDITION MET is returned whenever the requested operation is satisfied (see the SEARCH DATA and PREFETCH commands). BUSY. This status indicates that the target is busy. This status shall be returned whenever a target is unable to accept the command 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. If a reservation conflict exists, that status shall be presented before a BUSY status is presented to correctly inform the host system of conditions in the target controller. 123 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 INTERMEDIATE. This status or INTERMEDIATE-CONDITION MET shall be returned for every successfully completed command in a series of linked commands (except the last command), unless the command is terminated with CHECK CONDITION, RESERVATION CONFLICT, or COMMAND TERMINATED status. If INTERMEDIATE or INTERMEDIATE-CONDITION MET status is not returned, the series of linked commands is terminated and the I/O process is ended. INTERMEDIATE-CONDITION MET. This status is the combination of the CONDITION MET and INTERMEDIATE statuses. RESERVATION CONFLICT. This status shall be returned whenever an initiator attempts to access 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 issue the command again at a later time. COMMAND TERMINATED. This status shall be returned whenever the target terminates the current I/O process after receiving a TERMINATE I/O PROCESS message (see 6.5.29). This status also indicates that a contingent allegiance condition exists (see 6.11). QUEUE FULL. This status shall be implemented if tagged queuing is implemented. This status is returned when a SIMPLE QUEUE TAG, ORDERED QUEUE TAG, or HEAD OF QUEUE TAG message is received and the command queue is full. The I/O process is not placed in the command queue. 6.9. Command Examples The following sections give examples of typical command processing in the SCSI environment. Multiple path operation is not described in these examples. An alternative method for handling I/O processes is defined which uses information packets. The examples below will describe both methods of operation. 6.9.1. Single Command Example An I/O process containing one untagged READ command is used in this section to illustrate a simple I/O process on the SCSI bus. This example does not include error or exception conditions. The initiator has one set of active pointers that includes a command pointer, a data pointer, and a status pointer. In addition, the initiator has one set of saved pointers for each I/O process that it is able to concurrently manage. The initiator sets up the saved pointers to point to the appropriate bytes for the I/O process and copies the saved pointers to the active pointers. It then arbitrates for the SCSI bus, and upon winning arbitration, selects the target. Once the target is selected, the target assumes control of the I/O process. 124 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The initiator does not grant the target the privilege of disconnecting from the SCSI bus. 6.9.1.1. Using SCSI-2 Information Transfer Phases During the SELECTION phase, the initiator asserts the ATN signal to inform the target that the initiator wishes to send a message. The target enters the MESSAGE OUT phase and transfers the IDENTIFY message from the initiator. This message informs the target of which logical unit is to be used. At this point, an I_T_L nexus has been established for the I/O process. This nexus associates the initiator's pointers with the I/O process. The target switches to the COMMAND phase and transfers the command descriptor block from the initiator. In this case, the command descriptor block contains a READ command. The target interprets the command and switches to the DATA IN phase, transfers the data, switches to STATUS phase, sends GOOD status, switches to MESSAGE IN phase, and transfers a COMMAND COMPLETE message. After successfully sending the COMMAND COMPLETE message, the target disconnects and the I/O process ends. 6.9.1.2. Using Nexus Transfer Information Transfer Phases (Parallel) During the SELECTION phase, the initiator causes the attention condition inform the target that the initiator wishes to send an information packet. The target enters the NEXUS TRANSFER OUT phase and transfers an information packet from the initiator. The first interface logical element in the information packet is a message group with the first message being an INFORMATION PACKET IDENTIFY message. This message informs the target which logical unit is to be used. At this point, an H_I_T_C_L nexus has been established for the I/O process, since the disconnect privilege is not granted. This nexus associates the initiator's pointers with the I/O process. The second interface logical element in the information packet is a command descriptor block for the READ command. The target interprets the command. The target prepares an information packet with the data read from the logical unit. The target then switches to the NEXUS TRANSFER IN phase and transmits the information packet containing the data. This information packet also contains, after the data interface logical element, interface logical elements for status and messages. The message interface logical element contains the COMMAND COMPLETE message. After successfully sending the information packet, the target disconnects. 6.9.2. Disconnect Example In the above single command example, the length of time necessary to obtain the data may require a time-consuming physical positioning operation. In order to improve SCSI bus performance, the target may be permitted to disconnect from the initiator, allowing other I/O processes to use the SCSI bus. 125 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 In this case, the initiator grants the target the privilege of disconnecting from the SCSI bus. The INFORMATION PACKET IDENTIFY has the SuspMpth bit set to 1 to force an H_I_T_C_L nexus. 6.9.2.1. Using SCSI-2 Information Transfer Phases After the target has received the READ command (and has determined that there will be a delay), it disconnects from the SCSI bus by sending a DISCONNECT message and then disconnecting. After the target retrieves the requested data from the peripheral device it arbitrates for the SCSI bus. Upon winning arbitration, it reselects the initiator and sends an IDENTIFY message to the initiator via the MESSAGE IN phase. This revives the I_T_L nexus so that the initiator can retrieve the correct set of pointers for the I/O process. The initiator restores the active pointers to their most recent saved values (which, in this case, are the initial values) and the target continues (as in the single command example) to finish the I/O process. If target wishes to disconnect after transferring part of the data (e.g., while crossing a cylinder boundary), it may do so by sending a SAVE DATA POINTER message and a DISCONNECT message to the initiator and then disconnecting. When reconnection is completed, the current data pointer is restored to its value immediately prior to the SAVE DATA POINTER message. On those occasions when an error or exception condition occurs and the target elects to repeat the information transfer, the target may repeat the transfer by either issuing a RESTORE POINTERS message or by disconnecting without issuing a SAVE DATA POINTER message. When reconnection is completed, the most recent saved pointer values are restored. 6.9.2.2. Using Nexus Transfer Information Transfer Phases (Parallel) After the target has received information packet with INFORMATION PACKET IDENTIFY message and the READ command the target automatically disconnects from the SCSI bus. This is not an unexpected disconnect condition since the disconnect privilege was granted to the target. After the target retrieves the requested data from the peripheral device it prepares an information packet with a message interface logical element containing an INFORMATION PACKET IDENTIFY message followed by a data interface logical element and then arbitrates using the same SCSI bus on which the connect was made. This information packet also contains, after the data, interface logical elements for status and messages. The message interface logical element contains the COMMAND COMPLETE message. Upon winning arbitration, it reselects the initiator and sends the information packet using the NEXUS TRANSFER IN phase. This revives the H_I_T_C_L nexus so that the initiator can retrieve the correct set of pointers for the I/O process. The initiator sets the active pointers to the most recently saved values for the I/O process (which, in this case, are the initial values) and the target continues (as in the single command example) to finish the I/O process. After successfully sending the information packet, the target disconnects. 126 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 If target wishes to disconnect after transferring part of the data (e.g., while crossing a cylinder boundary), it may do so by placing only part of the data in the information packet above and omitting the status and message interface logical elements following the data. After successfully sending the information packet, the target disconnects. The initiator automatically saves the data pointers. One or more additional information packets containing the message and data interface logical elements is prepared and sent using the procedure described for the first information packet. Each reconnection causes the initiator to automatically restore the I/O process pointers to the active pointers. The last information packet may contain data, but it must contain the status and message interface logical elements in addition to the required message elements to reestablish the nexus. On those occasions when an error or exception condition occurs and the target elects to repeat the information transfer, the target may repeat the transfer by preparing an information packet containing a MODIFY DATA POINTERS message in the message interface logical element before the data element. At the end of the information packet transfer the pointers are once again automatically saved. 6.9.3. Linked Command Example In this example there is no difference in the logical actions taken by either the initiator or the target whether the SCSI-2 information transfer phases or the nexus transfer information transfer phases are used. The physical difference is that the initiator and target either use an explicit sequence of information transfer phases followed by the appropriate bytes or the initiator and target prepare information packets with the interface logical elements in the correct order and use only the nexus transfer phase. An I/O process may contain multiple commands "linked" together. Upon completing a linked command successfully, the target automatically proceeds to the next linked command for the I/O process. All commands in a series of linked commands are addressed to the same nexus and are part of a single I/O process. The commands are not entirely independent. When using the relative address bit (see 8.1.10), the address of the last logical block accessed by one of the commands is available to the next command. Thus one can search for a particular data pattern using a SEARCH DATA command and then read the logical block containing the data pattern with a READ command linked to the SEARCH DATA command. One can also read a logical block at a specified displacement from the block containing the data pattern. A LINKED COMMAND COMPLETE or LINKED COMMAND COMPLETE (WITH FLAG) message is sent from the target to the initiator to indicate that a linked command completed. The initiator then updates the saved pointers for the nexus so that subsequent transfers from the target reference the next command of the 127 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 series. Command processing of linked and single commands is similar except that relative addressing is permitted in linked commands. For example, a successful completion of a SEARCH DATA EQUAL command causes the target to continue with the linked READ command from the initiator. If the relative address bit in the READ command has been set to one, and the address field of the READ command is set to zero, the target transfers the successfully searched block to the initiator. 6.10. Command Processing Considerations and Exception Conditions The following sections describe some exception conditions and errors associated with command processing and the sequencing of commands. 6.10.1. Programmable Operating Definition Some applications require that the operating definition of a logical unit be modified to meet the special requirements of a particular initiator. The program-controlled modification of the operating definition is typically provided to allow operating systems to change the operating definition of a more recently developed targets to one which is more compatible with the operating system. Invoking this function requires that the initiating controller and its initiators comply with the low-level hardware definitions of SCSI-2. 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 operating definition. The present operating definition of a logical unit with respect to an initiator can be determined at any time by execution of an INQUIRY command. In some vendor-specific cases, it may also 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 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 should continue to accept the CHANGE DEFINITION command. If an error occurs during execution of a CHANGE DEFINITION command, the original operating definition remains in effect after the command is executed. The new operating definition becomes active only after successful execution of the CHANGE DEFINITION command. Since new operating definitions may preclude the execution of I/O processes that are already in progress, the target may disconnect to allow completion of any I/O processes that are in progress. Operating definition changes that 128 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 may cause conflicts with the normal operation from other initiators shall be indicated to those initiators by generating a unit attention condition for each other initiator. The additional sense code shall be set to CHANGED OPERATING DEFINITION. An initiator may request a list of the operating definitions that the target supports and descriptive text for each operating definition using the INQUIRY command. 6.10.2. Incorrect Initiator Connection An incorrect initiator connection occurs on a reconnection if: (1) an initiator attempts to reconnect to an I/O process, and (2) a soft reset condition has not occurred, and (3) the initiator does not send an ABORT, ABORT TAG, BUS DEVICE RESET, CLEAR QUEUE, or TERMINATE I/O PROCESS message during the same MESSAGE OUT phase as the IDENTIFY message or in the same information packet as the INFORMATION PACKET IDENTIFY message. An incorrect initiator connection also occurs on an initial connection when an initiator: (1) attempts to establish an I_T_L_Q nexus when an I_T_L nexus already exists from a previous connection for the same I, T, and L values, or (2) attempts to establish an I_T_L nexus when an I_T_L_Q nexus already exists unless there is a contingent allegiance or extended contingent allegiance condition present for the logical unit or target routine; or (3) 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 (4) 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 that detects an incorrect initiator connection shall abort all I/O processes for the initiator on the logical unit or target routine and shall return CHECK CONDITION status. The sense key shall be set to ABORTED COMMAND and the additional sense code shall be set to OVERLAPPED COMMANDS ATTEMPTED. If an initiator reconnects to an I/O process and a soft reset condition has occurred, the target shall meet the requirements of 5.2.2.2. IMPLEMENTORS NOTES: (1) An incorrect initiator connection may be indicative of a serious error and, if not detected, could result in an I/O process operating with a wrong set of pointers. This is considered a catastrophic failure on the part of the initiator. Therefore, vendor-specific error recovery procedures may be 129 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 required to guarantee the data integrity on the medium. The target may return additional sense data to aid in this error recovery procedure (e.g., sequential-access devices may return the residue of blocks remaining to be written or read at the time the second command was received). (2) Some targets may not detect an incorrect initiator connection until after the command descriptor block has been received. 6.10.3. Selection of an Invalid Logical Unit The target's response to selection of a logical unit which is not valid is described in the following paragraphs. The logical unit may not be valid because: (1) the target does not support the logical unit (e.g., some targets support only one peripheral device). 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 any other command except REQUEST SENSE the target shall terminate the command with CHECK CONDITION status. In response to a REQUEST SENSE command the target shall return sense data. 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 supports the logical unit, but the peripheral device is not currently attached to the target. 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 any other command except REQUEST SENSE the target shall terminate the command with CHECK CONDITION status. In response to a REQUEST SENSE command the target shall return sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED. (3) the target 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. The target's response to any command other than INQUIRY and REQUEST SENSE is vendor specific. (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 the target shall return the REQUEST SENSE data with a sense key of NO SENSE unless a prior error condition exists. The target's response to any other command is vendor specific. 6.10.4. Parameter Rounding Certain parameters sent to a target with various commands contain a range of values. Targets may choose to implement only selected values from this range. When the target receives a value that it does not support, it either 130 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 rejects the command (CHECK CONDITION status with ILLEGAL REQUEST sense key) or it rounds the value received to a supported value. The target 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 that receives a parameter value that is not an exact supported 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 initiator is responsible to issue an appropriate command to learn what value the target 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 initiator. Minimum-value fields should be rounded up to the next higher supported value than the one specified by the initiator. In some cases, the type of rounding (up or down) is explicitly specified in the description of the parameter. 6.10.5. Unsuccessful I/O Process Termination Condition Upon detection of an unsuccessful I/O process termination condition, the target may 1) terminate the I/O process by clearing all pending data and status information for the affected logical unit or target routine. 2) terminate the I/O process by clearing all pending data and prepare sense data that may be retrieved by a REQUEST SENSE command. When an initiator detects an unexpected disconnect, it is recommended that a REQUEST SENSE command be attempted to obtain any valid sense data that may be available. 6.10.6. Reset Condition 6.10.6.1. Reset Condition (Parallel) The effect of the Reset condition on I/O processes which have not completed, SCSI device reservations, and SCSI device operating modes is determined by whether the SCSI device has implemented the hard reset alternative or the soft reset alternative (one of which shall be implemented) as defined in 6.10.6.2 and 6.10.6.3. The hard and soft reset alternatives are mutually exclusive within a system. A facility for targets to report which reset alternative is implemented is provided in the SftRe bit of the INQUIRY data (7.2.5). IMPLEMENTORS NOTE: Environmental conditions (e.g., static discharge) may generate brief glitches on the RST signal. It is recommended that SCSI devices not react to these glitches. The manner of rejecting glitches is vendor specific. The bus clear delay following a RST signal transition to 131 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 true is measured from the original transition of the RST signal, not from the time that the signal has been confirmed. This limits the time to confirm the RST signal to a maximum of a bus clear delay. 6.10.6.2. Hard Reset Alternative (Parallel) NOTE: The hard reset alternative is left in SCSI-3 for backward compatibility to SCSI-2. It is recommended that all SCSI-3 devices implement the soft reset alternative. Soft reset is mutually exclusive with the hard reset alternative in a logical system in SCSI-2. SCSI devices that implement the hard reset alternative, upon detection of the reset condition, shall: (1) Clear all I/O processes including queued I/O processes. (2) Release all SCSI device reservations. (3) Return any SCSI device operating modes to their appropriate initial conditions, similar to those conditions that would be found after a normal power-on reset. MODE SELECT conditions shall be restored to their last saved values if saved values have been established. MODE SELECT conditions for which no values have been saved shall be returned to their default values. (4) Unit attention condition shall be set (See 6.13). It is recommended that following a reset to selection time after a hard reset condition ends, SCSI targets be able to respond with appropriate status and sense data to the TEST UNIT READY, INQUIRY, and REQUEST SENSE commands. 6.10.6.3. Soft Reset Alternative (Parallel) SCSI devices that implement the soft reset alternative, upon detection of the reset condition, shall: (1) Attempt to complete any I/O processes which have not completed and that were fully identified (2) Preserve all SCSI device reservations (3) Preserve any SCSI 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 soft reset alternative allows an initiator to reset the SCSI bus with minimum disruption to the operation of other initiators in a multiple initiator 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 a) when not using information packets, the IDENTIFY message (and queue tag message, if any) is sent to the target and the target responds by 132 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 changing to any other information transfer phase and requests that at least one byte be transferred. b) when using information packets, during the next connection with the target for the same I/O process, the target provides no response in the information packet to indicate an error in the last information packet received. (2) A target shall consider an I/O process to be fully identified when a) when not using information packets, it successfully receives the IDENTIFY message and any queue tag message and the initiator negates the ATN signal, b) when using information packets, during the next connection with the same initiator for the same I/O process, the target reports no error in the last information packet received. (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 TAG message, depending on whether the I/O process is a tagged I/O process. When using information packets, the message is contained in an information packet. (5) An initiator shall consider an I/O process to be completed a) when not using information packets, it negates ACK for a successfully received COMMAND COMPLETE message, b) when using information packets, no error is detected in the transfer of an information packet containing the COMMAND COMPLETE message. (6) A target shall consider an I/O process to be completed a) when not using information packets, it detects the transition of ACK to false for the COMMAND COMPLETE message with the ATN signal false, b) when using information packets, it detects the end of the information packet transfer with the ATN signal false. (7) a) When not using informatin packets, an initiator shall not negate the ACK signal for the SAVE DATA POINTER message until it has actually saved the data pointer for the I/O process. b) When using information packets, an initiator shall not negate the ACK signal for an information packet until it has actually saved the active pointers for the current I/O process. The saved pointers must be updated before the initiator responds to a connection for another information packet for the same I/O process. (8) a) When not using information packets, a target shall consider the data pointer saved when it detects the transition of the ACK signal to false for the SAVE DATA POINTER message with the ATN signal false, b) When using information packets, a target shall consider the data pointer saved when it detects the transition of the ACK signal to false for each information packet. (9) a) When not using information packets, if the reset condition occurs between the time that the target asserts the REQ signal for the SAVE DATA POINTER message and it detects the transition of the ACK signal to false, the 133 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 target shall terminate the I/O process with CHECK CONDITION 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. b) When using information packets, if the reset condition occurs during the transfer of an information packet, the target shall terminate the I/O process with CHECK CONDITION 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. NOTE: If the ATN signal is true in conditions (6) or (8), the target would normally switch to MESSAGE OUT phase or NEXUS TRANSFER OUT phase and attempt to transfer a message byte or an information packet. If the reset condition occurs before the target successfully receives the message, it may assume that the initiator has not successfully received the COMMAND COMPLETE message or the SAVE DATA POINTER message. In the case of COMMAND COMPLETE message, the target may reselect the initiator and attempt to send the COMMAND COMPLETE message again. In the case of the SAVE DATA POINTER message, the target may reselect the initiator and terminate the I/O process as described in condition (9). 6.10.6.4. Reset Condition (Serial) The effect of the reset condition on I/O processes which have not completed, path groups, assignments, reservations, and SCSI device operating modes is determined in the following section. SCSI devices shall: (1) Attempt to complete any I/O processes which have not completed and that were fully identified (2) Preserve all SCSI device path groups, path group status, assignments, passwords and reservations, as appropriate (3) Preserve any SCSI 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 SCSI 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 134 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 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 TAG 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 COMMAND 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 COMMAND COMPLETE message. (7) When using informatin packets, an initiator shall not transmit an acknowledge information packet for an information packet until it has actually saved the pointers for the current I/O process. (8) A target shall consider the pointers saved when it detects the acknowledgement 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 CONDITION 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. 6.10.7. Asynchronous Event Notification Implementation of asynchronous event notification is optional protocol unless the SCSI device implements information packets; in that case it is mandatory. An asynchronous event is one which occurs in a target controller which affects the operation of the target controller with its initiating controller(s), but which does not occur as a result of an active I/O process. An example of an asynchronous event is medium removal in a sequential access device or a removable optical device or a CD_ROM. An error condition or unit attention condition shall be reported once per occurrence of the event causing it (See contingent allegiance, Section 6.11.). The target may choose to use an asynchronous event notification or to return CHECK CONDITION status on a subsequent command, but not both. Notification of command-related error conditions shall be sent only to the initiating controller where the connect was made for the I/O process. SCSI devices that implement target mode, respond to an INQUIRY command as a processor device class, and report asynchronous event notification capability (AENC bit is set to 1) may be notified of asynchronous events using this 135 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 protocol. Such SCSI devices are normally initiators attached to an initiating controller. Asynchronous event notification may not be used with a device that acts as a temporary initiator (e.g., devices executing COPY commands), unless the SCSI device implements an active target mode, and responds correctly to the INQUIRY command as required above. The INQUIRY command should be issued to logical unit zero of each SCSI device responding to selection. An SCSI device, which normally functions as a target controller, must implement initiator mode to be capable notifying an initiating controller of an asynchronous event. Retrieval of the INQUIRY data by target controllers shall shall be performed prior to the first use of asynchronous event notification with an initiating controller through an initiator. Each SCSI device that implements the required functions and responses for receiving asynchronous event notification shall be issued a TEST UNIT READY command to determine that the SCSI device is ready to receive an asynchronous event notification. An SCSI device returning CHECK CONDITION status is issued a REQUEST SENSE command. This clears any pending unit attention condition. (??? before each AEN is reported; what if it is something else??? GRS) An SCSI device which implements the required functions and responses for receiving asynchronous event notification, defined above, and which returns 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 information identifying the condition being reported shall be returned as a command parameter data of the the SEND command (see 11.2.2.). The data sent is shown in Table 11-4. The procedure to identify candidate initiating controllers through their initiators shall be repeated whenever a target controller deems it appropriate or when an event occurs that may invalidate the current information. (See 6.5.27, SYNCHRONOUS DATA TRANSFER REQUEST message, for examples of these events.) This protocol is not intended to be used while an H_C_L nexus, an H_C_R nexus, an I_T_L nexus or I_T_L_Q nexus exists between an host system for the H_C nexus types or an initiator declared as a processor device class for the I_T nexus types. Asynchronous event notification is not intended for use with target routines (i.e., an H_C_R or I_T_R nexus) but its use is not prohibited. Parameters affecting the use of asynchronous event notification are contained in the control mode page (see 7.3.3.1). The four principal uses of asynchronous event notification are: (1) informing a processor of an error condition encountered after command completion; 136 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 (2) informing all processor devices that a newly initialized device is available; (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 or I_T_L nexus used for the asynchronous event notification. An example of the second case above is using the asynchronous event notification protocol to notify initiating controllers that a system resource has become available. If a target chooses to use this method, the sense key in the sense data sent to the initiating controller shall be set to UNIT ATTENTION. The alternative is to set a UNIT ATTENTION condition and then wait until selected. An example of the third case above is a device that supports removable media. Asynchronous event notification may be used to inform a host system 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. IMPLEMENTORS NOTE: An SCSI device which can use asynchronous event notification at initialization time should provide means to defeat these notifications. This can be done with a switch or jumper wire. Devices which implement saved parameters may alternatively save the asynchronous event notification permissions either on a per SCSI device basis or as a system wide option. In any case, each target controller conducts a survey with INQUIRY commands to be sure that the devices on the SCSI bus are appropriate destinations for asynchronous event notification. (The devices on the bus or the SCSI ID assignments may have changed.) 6.11. Contingent Allegiance Condition Implementation of Contingent allegiance is a mandatory. The contingent allegiance condition shall exist following the return of CHECK CONDITION or 137 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 COMMAND TERMINATED status and may optionally exist following an unexpected disconnect. The contingent allegiance condition shall be preserved for the H_C_x nexus or I_T_x nexus, on the H_I_T_C path where it is reported, until it is cleared. The type of nexus and conditions in effect 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 I_T_x nexus. If the subsequent command is a REQUEST SENSE command, the sense data is reported in response to the command and then cleared. While the contingent allegiance condition exists the target shall preserve the sense data. 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 queued 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. 6.12. Extended Contingent Allegiance Condition Implementation of extended contingent allegiance is optional. The extended contingent allegiance condition extends the contingent allegiance condition for an H_C_x nexus or an I_T_x nexus. This condition is generated by the target sending an INITIATE RECOVERY message on the same path as and following the CHECK CONDITION or COMMAND TERMINATED status and prior to the COMMAND COMPLETE message. This condition shall be preserved until it is cleared by a BUS DEVICE RESET message, a RELEASE RECOVERY message, or a hard reset condition. 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 queued commands for the logical unit for which the extended contingent allegiance condition exists shall be suspended until the extended contingent allegiance condition is reset. If the device wishes to generate an extended contingent allegiance condition during an asynchronous event notification (6.10.7), it shall send an INITIATE RECOVERY message following the IDENTIFY message or INFORMATION PACKET IDENTIFY message (and following any queue tag message) and prior to the SEND command. An extended contingent allegiance condition can be generated for only one H_C_L or I_T_L nexus at a time. The extended contingent allegiance condition is cleared as defined above. when a RELEASE RECOVERY message is received from the device to 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 queue tag message the target shall respond with QUEUE FULL status. 138 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 After the extended contingent allegiance condition is cleared any commands remaining in the command queue shall be executed. It is not required to generate an extended contingent allegiance condition for every CHECK CONDITION or COMMAND TERMINATED status that occurs. Simple errors not requiring an extended recovery may be dealt with by using the contingent allegiance protocol. During the existence of the extended contingent allegiance conditi on, appropriate error recovery sequences may be executed. Such commands can correct data, modify or delete queued commands, perform LOG SENSE commands and obtain diagnostic information. Extended contingent allegiance is recommended for error conditions that may require execution of multiple-step error-recovery protocols without interference from other initiators. 6.13. 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 initiating controller until that initiating controller clears the condition as described in the following paragraphs. 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 contingent allegiance condition), the target shall perform the INQUIRY command and shall not clear the unit attention condition. If the 139 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 INQUIRY command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, then the unit attention condition on the logical unit shall be cleared, and the target shall perform the INQUIRY command. If any other command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, the unit attention condition on the logical unit shall be cleared, and if no other unit attention condition 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 contingent allegiance condition), then the target may either: (1) report any pending sense data and preserve the unit attention condition on the logical unit, or (2) report the unit attention condition, may discard any pending sense data, and clear the unit attention condition on the logical unit for that initiator. If the target has already generated the contingent allegiance condition for the unit attention condition, the target shall perform the second action listed above. If an initiator issues a command other than INQUIRY or REQUEST SENSE while a unit attention condition exists for that initiator (prior to 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 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). If a target becomes a temporary initiator to issue a SEND command with an AEN bit of one, which informs the initiator (temporary target) of the unit attention condition, and the SEND command completes with GOOD status, then the target shall clear the unit attention condition for that initiator on the logical unit. IMPLEMENTORS NOTES: (1) Targets may queue unit attention conditions on logical units. After the first unit attention condition is cleared, another unit attention condition may exist (e.g., a power on condition followed by a microcode change condition). The initiating controller can clear all pending unit 140 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 attention conditions by repeatedly sending the REQUEST SENSE command until a sense key other than UNIT ATTENTION is returned by the target. (2) See 6.10.3 for requirements concerning selection of an invalid logical unit. 6.14. Queued I/O Processes The implementation of queuing for I/O processes is optional. Queuing of I/O processes allows a target to accept multiple I/O processes for execution at a later time. There are two methods for implementation of queuing, tagged and untagged. Tagged queuing allows a target to accept multiple I/O processes from each initiating controller for each logical unit or target routine. Untagged queuing allows a target to accept one I/O process from each initiating controller for each logical unit. A target may be capable of both methods queuing, but only one method may be used at a time. Untagged queuing may be supported by SCSI-1 devices or devices whose level is at least SCSI-2. Tagged queuing is first supported in SCSI-2 devices. In the text that follows when information packets are being used, references to data transfer imply data interface logical elements in information packet are used. 6.14.1. Untagged Queuing Untagged queuing allows a target to accept a command from a host system for a logical unit or target routine while a command from another initiating controller is being executed. Only one command for each H_C_x nexus or I_T_x nexus shall be accepted at a time. An I/O process may be initiated any time the BUS FREE phase exists even if an I/O process from a different initiating controller is active. If the disconnect privilege is not granted in the IDENTIFY message or INFORMATION PACKET IDENTIFY message of the new I/O process, the target may either suspend the active I/O process or it may return BUSY status to the new I/O process. The H_C_x nexus or the I_T_x nexus sufficiently specifies the relationship so that the target can reconnect to the initiating controller to restore the pointers for I/O process as long as only one I/O process per H_C_x nexus or I_T_x nexus is issued. It is the responsibility of the initiator to assure that only one such I/O process is issued at any time (see 6.10.2). 6.14.2. Tagged Queuing Tagged queuing allows a target to accept multiple I/O processes from the same or different initiating controllers until the logical unit's command 141 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 queue is full. If an I/O process is received and the command queue is full, the target shall terminate the I/O process with QUEUE FULL status. The command queue is setup by the target for each supported logical unit and target routine (??? GRS). Initiating controllers may add or delete I/O processes to the 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. If the disconnect privilege is not granted in the IDENTIFY message or INFORMATION PACKET IDENTIFY message for a tagged I/O process the target shall return BUSY status. Optionally, since the initiator has made an error in the IDENTIFY message or INFORMATION PACKET IDENTIFY message, the target may return CHECK CONDITION status and prepare the appropriate sense data. The queue tag messages (see 6.5.22) allow the initiating controller to establish a unique H_C_L_Q nexus or I_T_L_Q nexus to identify each I/O process. The H_C_L_Q nexus or I_T_L_Q nexus allows the target to reconnect to a specific I/O process and allows the initiator for each connection to restore the set of pointers for that I/O process. An initiating controller may have several I/O processes ongoing to the same or different logical units or target routines (??? GRS) as long as each has a unique nexus. If only SIMPLE QUEUE TAG messages are used, the target may execute the commands in any order that is deemed desirable within the constraints of the queue management algorithm specified in the control mode page (see 7.3.3.1). If ORDERED QUEUE TAG messages are used, the target shall execute the commands in the order received with respect to other commands received with ORDERED QUEUE TAG messages. All commands received with an SIMPLE QUEUE TAG message prior to a command received with an ORDERED QUEUE TAG message, regardless of initiating controller, shall be executed before that command with the ORDERED QUEUE TAG message. All commands received with an SIMPLE QUEUE TAG message after a command received with an ORDERED QUEUE TAG message, regardless of initiating controller, shall be executed after that command with the ORDERED QUEUE TAG message. A command received with a HEAD OF QUEUE TAG message is placed first in the queue, to be executed next. A command received with a HEAD OF QUEUE TAG message shall not suspend an active I/O process in the target. Consecutive commands received with HEAD OF QUEUE TAG messages are executed in a last-in-first-out order. An I/O process received without a queue tag message while there are any tagged I/O commands in the command queue is an incorrect connection (see 6.10.2) unless there is a contingent allegiance or extended contingent allegiance condition. A series of linked commands are a single I/O process, and are assigned the queue tag established in the initial connection. A command received with a HEAD OF QUEUE TAG message shall not suspend a series of linked commands for which the target has begun execution. When using information packets, the complete series of commands may be transferred in one information packet. 142 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 The RESERVE and RELEASE commands should be sent with an ORDERED QUEUE TAG message. Use of the HEAD OF QUEUE TAG message with these commands could result in reservation conflicts with previously issued commands. The TEST UNIT READY and INQUIRY commands are often sent with a HEAD OF QUEUE TAG message, since the information returned has no effect on the condition of the logical unit. Two error recovery options are allowed. The error recovery option to be used is specified in the control mode page (see 7.3.3.1). The first post-recovery option is to continue execution of commands in the queue after the contingent allegiance or extended contingent allegiance condition has cleared. The target controller returns BUSY status to other initiating controller connects while the contingent allegiance or extended contingent allegiance condition exists. During this time all commands in the queue are suspended. All commands used for recovery operations shall be untagged commands. The queue may be modified by removing all or selected commands in the queue as part of the recovery procedure. If commands are combined by the queuing algorithm such that the error affects more than one command, then a contingent allegiance condition shall be generated for all affected commands. The second recovery option clears the queue 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 COMMANDS CLEARED BY ANOTHER INITIATOR. Deferred errors are normally related to a command that has already completed. As such, there is no attempt to return the queue tag value assigned to the original command. A device that does not support tagged queuing for any reason (e.g., not implemented, disabled by the DQue bit in the control mode page, or it has been switched to an operating definition that does not include tagged queuing) shall respond to any queue tag message with a MESSAGE REJECT message or EXTENDED MESSAGE REJECT message. The target shall continue the I/O process as if it was an untagged I/O process. (??? How does this work without initiator modified connects??? GRS) Tagged queuing may also be temporarily disabled internal to the SCSI device during certain initialization periods or to control internal resource utilization. During these periods the target may elect to return QUEUE FULL status or it may respond to any queue tag message with a MESSAGE REJECT message or EXTENDED MESSAGE REJECT message. (??? why two choices? message reject implies lack of function rather than suspended function. If the target controller is indisposed it should not indicate inappropriate; it should indicate inappropriate AT THIS TIME by the QUEUE FULL message. GRS) 143 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Several messages may be used to clear part or all of the command queue. Refer to the ABORT, ABORT TAG, BUS DEVICE RESET, and CLEAR QUEUE messages in Section 5 for details. 6.14.3. Example of Queued I/O Process An example of I/O process queuing benefits from the consideration of the execution of a number of commands. After each command, the state of the queue kept in the target is shown to indicate the function actually performed by the queuing. All examples shown in this section assume that multiple path operation is not being used. 6.14.3.1. Typical Sequences for Tagged Queuing An I/O process using tagged queuing uses the following sequences for normal execution. The initiator first arbitrates for the SCSI bus, and after successfully obtaining the SCSI bus, selects the appropriate SCSI device. The ATN signal is asserted during the SELECTION phase to indicate that a MESSAGE OUT phase is requested by the initiator. The first message byte transferred is an IDENTIFY message. The ATN signal continues to be asserted during the MESSAGE OUT phase to indicate that the initiator has another message. The second message byte transferred is the first byte of the appropriate queue tag message, in this case a SIMPLE QUEUE TAG message. The third and last message byte is transmitted containing the second byte of the queue tag message, the queue tag. As it is transferred, the ATN signal is negated to indicate that no more message bytes are available. The target then transfers the command descriptor block. Assuming the command requires disconnection, the target transmits a DISCONNECT message to the initiator and then disconnects. The target places the command, identified by the I_T_L_Q nexus, at the appropriate place in the command queue. When the target removes I/O processes from the queue for execution, a physical latency period may occur. At the end of this period, when the target is prepared to transfer the appropriate data, the target begins an ARBITRATION phase and, upon winning, enters a RESELECTION phase. After a successful reselection, the target sends the IDENTIFY message followed by a SIMPLE QUEUE TAG message with the queue tag value originally sent by the initiator. The initiator uses the I_T_L_Q nexus to identify the correct set of pointers and control blocks associated with the I/O process and to establish the necessary conditions for data transfer. The target begins data transfer. When the data transfer is successfully completed, the target returns GOOD status and terminates the I/O process with a COMMAND COMPLETE message. 6.14.3.2. Example of Tagged Queuing An example of the execution of five queued I/O processes is described to demonstrate how tagged queuing operates. All tagged I/O processes are from one initiator to a single logical unit of a single target. The five I/O processes are defined in Table 6-1s. The target is a direct-access device. At the time the I/O processes are first being executed, it is assumed that the actuator is in position to access logical block 10000. 144 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 Table 6-1s: Commands in Order Received by Target Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ SIMPLE 01h 10000 1000 Queued READ SIMPLE 02h 100 1 Queued READ ORDERED 03h 1000 1000 Queued READ SIMPLE 04h 10000 1 Queued READ SIMPLE 05h 2000 1000 Queued The optimum order would require that those blocks close to the actuator position be the first blocks accessed, followed by those increasingly far from the actuator position. However, the command with queue tag 03h is an ordered I/O process, so that all simple I/O processes transferred previously must be executed before, while all simple I/O processes transferred after the ordered I/O process must be executed after the ordered I/O process. If a target supports an optimizing algorithm the actual order in which the I/O processes are executed could be as shown in Table 6-1t. Table 6-1t: Commands in Order of Execution Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ SIMPLE 01h 10000 1000 Queued READ SIMPLE 02h 100 1 Queued READ ORDERED 03h 1000 1000 Queued READ SIMPLE 05h 2000 1000 Queued READ SIMPLE 04h 10000 1 Queued I/O processes with queue tag values 01h and 02h are executed in the order received since the actuator is already in position to execute I/O process 01h. I/O process 02h must be executed before I/O process 04h or 05h because the ordered I/O process 03h was transmitted after I/O processes 01h and 02h but before I/O processes 04h and 05h. I/O process 03h is then executed after I/O process 02h. The I/O processes 04h and 05h are executed after the ordered I/O process 03h. I/O process 05h is executed before I/O process 04h because the actuator is in position to access block 2000 after executing I/O process 03h. I/O process 04h is executed last. As an example of the operation of the HEAD OF QUEUE TAG I/O process, consider that a new I/O process, identified by a HEAD OF QUEUE TAG message with a queue tag of 08h, is transmitted to the target while the ordered I/O process 03h is being executed. The I/O process 03h continues execution, but the new HEAD OF QUEUE TAG I/O process is placed in the queue for execution before all subsequent I/O processes. In this case, the queue for execution 145 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 after the ordered I/O process 03h was executed would appear as shown in Table 6-1u. Table 6-1u: Modified by HEAD OF QUEUE TAG Message Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ ORDERED 03h 1000 1000 Executing READ HEAD OF QUEUE 08h 0 8 Queued READ SIMPLE 05h 2000 1000 Queued READ SIMPLE 04h 10000 1 Queued To obtain maximum performance gains using tagged queuing requires careful implementation of the queuing algorithms in the target. In addition, initiators should allow a maximum number of simple I/O processes to be executed with a minimum number of ordered I/O processes. RESERVE and RELEASE commands, SET LIMITS commands, and appropriate software locking conventions should be used to guarantee the proper relationship between the commands executed and the data stored on the peripheral devices. These conventions are not defined by this standard. 146 SCSI-3 ADDITIONS for Packetization/Serial Interface SCSI WORKING DOCUMENT X3T9.2/90-132 R00 7.x.z. SCSI-3 Path Control Commands and SCSI-2 Command Changes The path control commands required to carry out the logical operation model are: 1) SET ICID. Explicitly name the initiating controller using this path on which a connect occurred, establish and disband groups. 2) REPORT PATH STATUS. Report the status of the path relative to path groups. This is a singular command 3) ASSIGN. Define the path groups on which a logical unit may operate. This is a supervisor command. 4) UNASSIGN. Remove a path group from the set of authorized path groups granted access to a logical unit. This is a supervisor command. 5) The SCSI-2 functions in the RESERVE and RELEASE commands must be included in the ASSIGN and UNASSIGN commands. 6) CONTROL ACCESS. Transfer password on an assigned path to the target controller for a path group; permit general unassign from an assigned path group; and, allow an unassigned path, having the correct password, access to a logical unit for one I/O process. This is a supervisor command. 7) SUSPEND DYNAMIC PATH OPERATIONS. Suspend for the length of a single I/O process the use of dynamic path operation. All reconnects occur on the path where the connect occurred. This is a message level control as opposed to the command level control in item 8) which causes a general suspension of dynamic pathing operations within the path group. 8) SUSPEND DYNAMIC PATH OPERATIONS. Suspend the use of dynamic path reconnection even though the path group is correctly formed. All reconnects occur on the path where the connect occurred. 9) Considerations for when and how path groups are terminated and when and how assignment is terminated must be clearly stated. The exact formats and processing rules are TBD. However, they obey the rules of the logical operations model. 147 SCSI WORKING DOCUMENT X3T9.2/90-132 R00 END OF DOCUMENT X3T9.2/90-132 R00 148 SCSI-3 ADDITIONS FOR PACKETIZATION/SERIAL INTERFACE