DRAFT Revision 18 August 10, 1995 Information technology - SCSI-3 Architecture Model Secretariat: Information Technology Industry Council T h i s i s a draft proposed American National Standard of Accredited Standards Committee X3. As such this is not a completed standard. The X3T10 Technical Committee may modify this document as a result of comment s received during public review and its approval as a standard. Use of the information contained here in is at your own risk. P e r m i s s i o n i s g r anted to members of X3, its technical committees, and their associated task groups to reproduce this document for the purposes of X3 standardization activities without further permission, provided this notice is included. All other rights are reserved. Any commercial or for-profit duplication is strictly prohibited. ASC X3T10 Technical Editor: Charles Monia Digital Equipment Corporation SHR3-2/C5 334 South Street Shrewsbury, MA 01545 USA Telephone: 508-841-6757 Facsimile: 508-841-6100 Email: monia@shr.dec.com Reference number ISO/IEC **** : 199x ANSI X3.270 - 199x Printed August, 10, 1995 7:21pm atend X3T10/994D revision 18 August 10, 1995 POINTS OF CONTACT: X3T10 Chair X3T10 Vice-Chair John B. Lohmeyer Larry Lamers NCR Corporation Adaptec, Inc. 1635 Aeroplaza Drive 4611 Park Norton Place Colo Spgs, CO 80916 San Jose, CA 95136 Tel: \(719\ Tel: \(408\ Fax: \(719\ Fax: \(408\ Email: john.lohmeyer@ftcollinsco.ncr.com Email: ljlamers@aol.com X3 Secretariat Lynn Barra Administrator Standards Processing X3 Secretariat Telephone: 202-626-5738 1250 Eye Street, NW Suite 200 Facsimile: 202-638-4922 Washington, DC 20005 SCSI Reflector Internet address for subscription to the SCSI reflector: scsiadm@wichitaks.ncr.com Internet address for distribution via SCSI reflector: scsi@wichitaks.ncr.com SCSI Bulletin Board 719-574-0424 Document Distribution Global Engineering Telephone: 303-792-2181 or 15 Inverness Way East 800-854-7179 Englewood, CO 80112-5704 Facsimile: 303-792-2192 ABSTRACT T h i s s t a n d a r d s p e c i f i e s t h e S C S I A r c h i t e c t u r e M o d e l . The purpose of the architecture is to provide a common basis for t h e coordination of SCSI-3 standards and to specify those aspects of SCSI-3 I/O system behavior which ar e independent of a particular technology and common to all implementations. PATENT STATEMENT CAUTION: The developers of this standard have requested that holder's of patents that may be required for the i m p l e mentation of the standard, disclose such patents to the publisher. However, neither the developers nor the publisher have undertaken a patent search in order to identify which, if any, patents may apply to this standard. A s o f t h e d a t e o f p u b l i c a t i o n o f t h i s s t a n d a r d a n d f o l l o w i n g calls for the identification of patents that may be required for the implementation of the standard, no such claims have been made. No further patent search is conducted b y t h e d e v e l o p e r o r t h e p u b l i s h e r i n r e s p e c t t o a n y s t a n d a r d i t processes. No representation is made or implied that licenses are not required to avoid infringement in the use of this standard. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 3 Table of Contents Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1 Scope of the Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1 Scope of SCSI-3 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Architecture Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Implementation Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3.2 Device Access Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3.3 SCSI-3 Protocol Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3.4 Interconnect Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Glossary and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 References to SCSI Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Acronyms and Abbreviations: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4 Editorial Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5 Numeric Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 Reserved Fields and Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7 Objects and Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.1 Notation for Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.2 Object Addresses and Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7.3 Predefined Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7.4 Hierarchy Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8 Notation for Procedures and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.9 State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4 SCSI-3 Architecture Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2 The SCSI-3 Distributed Service Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3 The SCSI-3 Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4 The SCSI-3 Structural Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5 SCSI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.6 The Service Delivery Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.6.1 Synchronizing Client and Server States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.6.2 Request/Response Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.7 SCSI Device Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.7.1 SCSI Initiator Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.7.2 SCSI Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.7.3 The Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.7.4 Logical Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.8 The SCSI-3 Model for Distributed Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5 SCSI Command Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1 Command Descriptor Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1.1 Operation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.2 Control Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 Protocol Services in Support of Execute Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.3.1 Data Transfer Protocol Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 atend X3T10/994D revision 18 August 10, 1995 4 working draft SCSI-3 Architecture Model 5.3.2 Data-In Delivery Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3.3 Data-Out Delivery service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4 Task and Command Lifetimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.5 Command Processing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.5.1 Unlinked Command Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.5.2 Linked Command Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.6 Command Processing Considerations and Exception Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.6.1 Auto Contingent Allegiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.6.1.1 Logical Unit Response to Auto Contingent Allegiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.6.1.2 Clearing an Auto Contingent Allegiance Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.6.2 Overlapped Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.6.3 Incorrect Logical Unit Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.6.4 Sense Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.6.4.1 Asynchronous Event Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.6.4.2 Autosense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6.5 Unit Attention Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6.6 Hard Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6 Task Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.1 ABORT TASK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.2 ABORT TASK SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.3 CLEAR ACA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.4 CLEAR TASK SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.5 TARGET RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.6 TERMINATE TASK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.7 Task Management Protocol Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.8 Task Management Function Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7 Task Set Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.2 Task Management Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3 Task Abort Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4 Task States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4.1 Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4.2 Blocked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4.3 Dormant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.4.4 Ended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.5 Task Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.5.1 SIMPLE Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.5.2 ORDERED Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.5.3 HEAD OF QUEUE Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.5.4 ACA Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.6 Task State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.7 Task Set Management Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.7.1 Blocking Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.7.2 HEAD OF QUEUE Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.7.3 Ordered Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.7.4 ACA Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.7.5 Deferred Task Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 5 Object Definitions Object Definition 1 SCSI Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Object Definition 2 : Service Delivery Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Object Definition 3 : SCSI Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Object Definition 4: Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Object Definition 5 : Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Object definition 6 : Logical Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Object Definition 7 : Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figures Figure 1 : Requirements Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Figure 2 : Functional Scope of SCSI-3 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Figure 3 : Example of Hierarchy Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figure 4 : State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 5 : Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 6 : SCSI Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 7 : SCSI I/O System and Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 8 : SCSI Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 9 : Domain Functional Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 10 : Domain Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 11 : Service Delivery Subsystem Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 12 : SCSI Device Functional Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figure 13 : SCSI Device Hierarchy Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figure 14 : Target Object Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figure 15 : Logical Unit Object Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figure 16 : Protocol Service Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 17 : Protocol Service Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Figure 18 : Request-Response ULP Transaction and Related LLP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 19 : Model for buffered data transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 20 : Command processing events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Figure 21 : Linked Command Processing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Figure 22 : Task Management Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figure 23 : Example of Dormant Task Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figure 24 : Task States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Figure 25 : HEAD OF QUEUE Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Figure 26 : HEAD OF QUEUE Tasks and Blocking Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Figure 27 : Ordered Tasks and Blocking Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 28 : ACA Task Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figure 29 : Example of Deferred Task Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 atend X3T10/994D revision 18 August 10, 1995 6 working draft SCSI-3 Architecture Model List of Tables Table 1 -- Format of Command Descriptor Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Table 2 -- Operation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Table 3 -- Control Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Table 4 -- Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 atend scope.wp August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 7 Foreword T h e purpose of this standard is to provide a basis for the coordination of SCSI-3 standards development and t o d e f i n e r e q u i r e m e n t s , c o m m o n t o a l l S C S I - 3 t e c h n o l o g i e s a n d i m p lementations, which are essential for compatibility w i t h host SCSI-3 application software and device-resident firmware across all SCSI-3 protocols. Thes e r e q u i r e m e n t s are defined through a reference model which specifies the behavior and abstract structure which is generic to all SCSI-3 I/O system implementations. A s w i t h a n y o t h e r t e c h n i c a l d o c u m e n t , t h e r e m a y a r i s e q u e s t i o n s o f i n t e r p r e t a t ion as new products are implemented. The X3 Committee has established procedures to issue technical opinions concerning the standards developed b y t h e X 3 o r g a n i z ation. These procedures may result in SCSI Technical Information Bulletins being published by X3. T h e s e Bulletins, while reflecting the opinion of the Technical Committee which developed the standard, ar e i n t e n d e d s o l e l y a s s u p p l e m e n t a r y i n f o r m ation to other users of the standard. This standard, ANS X3.270-199x, as a p p r o v e d t h r o u g h t h e p u b l i c a t i o n a n d v o t i n g p r o c e d u r e s of the American National Standards Institute, is not altered b y t h e s e b u l l e t i n s . A n y s u b s e q u e n t r e v i s i o n t o t h i s standard may or may not reflect the contents of these Technical Information Bulletins. T e c h n i c a l C o m m i t t e e X 3 T 1 0 o n L o w e r L e v e l I n t e r f a c e s , w h i c h d e v e l o p e d t h i s s t a ndard, had the following members: John B. Lohmeyer, Chair Lawrence J. Lamers, Vice-Chair Ralph O. Weber, Secretary I. Dal Allan Bob Masterson Michael Wingard Paul D. Aloisi David McFadden Mark Woithe Ron Apt James McGrath Ezra Alcudia \(Alt.\ Geoffrey Barton Pete McLean Michael Alexenko \(Alt.\ Robert Bellino Patrick Mercer Steven A. Anderson \(Alt.\ Charles Brill Gene Milligan David Andreatta \(Alt.\ Peter Brown Charles Monia Tak Asami \(Alt.\ Michael Bryan Dennis P. Moore Akram Atallah \(Alt.\ Joe Chen Ian Morrell Paul Boulay \(Alt.\ Chris D'Iorio John Moy Kevin Calvert \(Alt.\ Joe Dambach S. Nadershahi John Cannon \(Alt.\ Jan V. Dedek Erich Oetting Kurt Chan \(Alt.\ Stephen G. Finch Alan R. Olson Shufan Chan \(Alt.\ Edward Fong Dennis Pak Ting Li Chan \(Alt.\ Louis Grantham Duncan Penman Mike Chenery \(Alt.\ Norm Harris George Penokie Nancy Cheng \(Alt.\ Edward Haske Doug Piper William Clemmey \(Alt.\ Dennis R. Haynes Donna Pope Dan Colegrove \(Alt.\ Stephen F. Heil Robert Reiseh Roger Cummings \(Alt.\ Stephen Holmstead Scott Smyers Zane Daggett \(Alt.\ David Hudson Robert N. Snively William Dallas \(Alt.\ Peter Johansson Jeff Stai Varouj Der-Hacopian \(Alt.\ Gerry Johnsen Gary R. Stephens Skip Jones Clifford E. Strang Jr. Edward Lappin Thomas 'Rick' Tewell Joe Lawlor Dean Wallace David Lawson Harvey Waltersdorf Robert Liu Gary M. Watson atend X3T10/994D revision 18 August 10, 1995 8 working draft SCSI-3 Architecture Model Dhiru N. Desai \(Alt.\ Mike Hetzel \(Alt.\ John Masiewicz \(Alt.\ Mike Eneboe \(Alt.\ Gerald Houlder \(Alt.\ Daniel E. Moczarny \(Alt.\ Timothy Feldman \(Alt.\ Paul Jackson \(Alt.\ E.J. Mondor \(Alt.\ Edward A. Gardner \(Alt.\ Kevin James \(Alt.\ Jay Neer \(Alt.\ John Geldman \(Alt.\ Brian Johnson \(Alt.\ Tim Norman \(Alt.\ Chuck Grant \(Alt.\ Mark Jordan \(Alt.\ Vit Novak \(Alt.\ Peter Haas \(Alt.\ Richard Kalish \(Alt.\ Kevin R. Pokorney \(Alt.\ Douglas Hagerman \(Alt.\ Greg Kapraun \(Alt.\ Gary Porter \(Alt.\ Kenneth J. Hallam \(Alt.\ Thomas J. Kulesza \(Alt.\ Doug Prins \(Alt.\ William Ham \(Alt.\ Dennis Lang \(Alt.\ Steven Ramberg \(Alt.\ Tom Hanan \(Alt.\ Bill Mable \(Alt.\ Ron Roberts \(Alt.\ Rick Heidick \(Alt.\ Gerald Marazas \(Alt.\ John P. Scheible \(Alt.\ Nicos Syrimis \(Alt.\ Jeffrey L. Williams \(Alt.\ J. R. Sims \(Alt.\ Pete Tobias \(Alt.\ Kurt Witte \(Alt.\ Michael Smith \(Alt.\ Adrienne Turenne \(Alt.\ Devon Worrell \(Alt.\ Allen Spalding \(Alt.\ Joseph Wach \(Alt.\ Charles I. Yang \(Alt.\ Arlan P. Stone \(Alt.\ Roger Wang \(Alt.\ Danny Yeung \(Alt.\ Joe Stoupa \(Alt.\ Dave Weber \(Alt.\ Mike Yokoyama \(Alt.\ George Su \(Alt.\ Bob Whiteman \(Alt.\ SI-3 Architecture Model SI-3 Implementation Generic requirements Implementation requirements SC SI-3 Implementation Standard SC SI-3 Implementation Standard SC SI-3 Implementation Standard August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 9 Figure 1 : Requirements Precedence 0. Introduction T h i s s p e c i f i c a t i o n d e s c r i b e s a reference model for the coordination of standards applicable to SCSI-3 I/O systems a n d a s e t o f c o m m o n b e h a v i o r a l r e q u i r e m e n t s w h i c h a r e e s sential for the development of host software and device firmware that can interoperate with any SCSI-3 interconnect or protocol. 1 Scope of the Architecture T h e s e t o f S CSI-3 standards consists of the SCSI-3 Architecture Model \(this specification\ and the SCSI- 3 implementation standards described in 1.1. T h i s s t a n d a r d d e f i n e s g e n e r i c r e q u i r e m e n t s , w h i c h p e r t a i n t o S C S I - 3 i m p l e m e n t a t ion standards, and implementation r e q u i r e m e n t s . A n i m p l e m e n t a t i o n r e q u i r e m e n t s p e c i f i e s b e h a v i o r in terms of measurable or observable parameters w h i c h a p p l y d i r e c t l y t o a n i m p l e m e n t a t i o n. Examples of implementation requirements defined in this document are the command descriptor block format and the status values to be returned upon command completion. G e n e r i c r e q u i r e m e n t s a r e t r a n s f o r m e d t o i m p l e m e n t a t i o n r e q u i r e m e n t s b y a n i m plementation standard. An example of a generic requirement is the hard reset behavior specified in subclause 5.6.6. A s shown in figure 1, all SCSI-3 implementation standards shall reflect the generic requirements defined herein. I n a d dition, an implementation claiming SCSI-3 compliance shall conform to the applicable implementatio n r e quirements defined in this standard and the appropriate SCSI-3 implementation standards. In the event of a c o n f l i c t b etween this document and other SCSI-3 standards under the jurisdiction of technical committee X3T10, the requirements of this standard shall apply. 1.1 Scope of SCSI-3 Standards Figure 2 uses a representative set of specifications to show the functional partitions and the relationships among SCSI-3 standards. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE SCSI-3 Interlocked Protocol \050SIP\051 SCSI-3 Parallel Interface \050SPI\051 SCSI-3 Fibre Channel Protocol \050FCP\051 Fibre Channel Physical and Signaling Interface \050FC-PH\051 IEEE 1394 High Performance Serial Bus SCSI-3 Serial Bus Protocol \050SBP\051 SCSI-3 SSP Protocol Serial Storage Architecture Bus \050SSA-PH\051 SCSI-3 Architecture Model \050SAM\051 Protocols Interconnects SCSI-3 Block Commands \050SBC\051 SCSI-3 Stream Commands \050SSC\051 SCSI-3 Graphic Commands \050SGC\051 SCSI-3 Medium Changer Commands \050SMC\051 SCSI-3 Primary Commands \050SPC\051 Commands Common Access Method \050CAM\051 X3T10/994D revision 18 August 10, 1995 10 working draft SCSI-3 Architecture Model Figure 2 : Functional Scope of SCSI-3 Standards The functional areas define the scope of each standard as follows: S C S I A r c h i tecture Model: Defines the SCSI systems model, the functional partitioning of the SCSI-3 standard set and requirements applicable to all SCSI-3 implementations and implementation standards. C o m m a n d s : I m p l e m e n t a t i o n s t a n d a r d s w h i c h d e f i n e d e v i c e c l a s s e s including a device model for each class. These standards specify the required commands and behavior that is common to all devices or unique to a given class of devices and prescribe the rules to be followed by an initiator when sending commands to a device. C o m m o n A c c e s s M e t h o d : I m p l e m e n t a t i o n s t a n d a r d w h i c h d e f i nes a host architecture and set of services for device access. P r o t o c o l s: Implementation standards which define the rules for exchanging information so that different SCSI- 3 devices can communicate. I n t e r c o n n e c ts: Implementation standards which define the electrical and signaling rules essential for devices t o interoperate over a given physical interconnect. T h e d i a g r a m o f figure 2 shows how the standards listed below fit within each category. The standards included in the diagram are meant to serve as examples and may not reflect the full set of standards currently in force. 1.2 Architecture Standard S C S I - 3 Architecture Model \(X3.270-199x\ SAM\ : Defines the functional partitions and specifies a model for S C S I - 3 I / O s y s t e m a n d d e v i c e b e h a v i o r w h i c h a p p l i e s to all SCSI interconnects, protocols, access methods and devices. atend WARNING -- glossary.wp must be created by merging glossary.pri and glossary.sec. glossary.pri DO NOT EDIT GLOSSARY.WP. This file is used as the formatting template to create glossary.wp, by merging with glossary.sec, which contains the alphabetically sorted glossary entries. To allow sorting with the WordPerfect sort tool, multi-word terms in the glossary are formatted with hard spaces between each word so sort will treat them as single-word entities. The last entry must be the delimiting string shown in the template. Sorting will cause this entry to always be placed last. August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 11 1.3 Implementation Standards 1.3.1 Commands SCSI-3 Primary Commands \(X3T10-995D\ SPC\ - Commands and device behavior common to all SCSI-3 target devices. SCSI-3 Block Commands \(X3T10-996D\ SBC\ - Block oriented SCSI-3 devices \(e.g., disks\ SCSI-3 Stream Commands \(X3T10-997D\ SSC\ - Stream-oriented SCSI-3 devices \(e.g., tape\ S C S I - 3 G r a p h i c s C o m m a n d s \( X 3 T 1 0 - 9 9 8 D \ \( S G C \ - G r a p h i cal input or output SCSI-3 devices \(e.g., printers\ S C S I - 3 Medium Changer Commands \(X3T10-999D\ \(SMC\ - SCSI-3 media changers such as CD/RO M carousels. S C S I - 3 C o n t r o l l e r C o m m a n d s \( X 3 T 1 0-XXXD\ SCC\ - SCSI-3 I/O subsystem controllers such as a disk array device controller. 1.3.2 Device Access Methods S C S I - 3 C ommon Access Method \(X3.332-199x\ CAM\ : A host architecture for performing SCSI device I/O. C A M d e f i n e s a l a y e r e d e n v i r o n m e n t a n d s e t o f s e r v i c e s , b a s e d o n the C computer language, which allow device drivers to be written that are independent of interconnects, protocols, operating systems and host platforms. 1.3.3 SCSI-3 Protocol Standards T h e following is a representative list of SCSI-3 protocol standards and the physical interconnects on which these are implemented. SCSI-3 Interlocked Protocol \(X3T10-856D\ SIP\ - SCSI-3 Parallel Interface. SCSI-3 Serial Bus Protocol \(X3T10-992D\ SBP\ - High Performance Serial Bus \(IEEE 1394\ Fibre Channel Protocol for SCSI \(X3T10-993D\ FCP\ - Fibre Channel interconnects. SCSI-3 Serial Storage Protocol \(X3T10-XXXX\ SSP\ - SCSI-3 Serial Storage Architecture. 1.3.4 Interconnect Standards SCSI-3 Parallel Interface \(X3T10-885D\ SPI\ Fibre Channel - PH \(X3T11-XXXX\ High Performance Serial Bus \(IEEE 1394\ Serial Storage Architecture - PH \(X3T10.1-XXX\ SSA\ 2 Normative References X3.131-1994 American National Standard Small Computer System Interface -2. 3 Glossary and Conventions atend X3T10/994D revision 18 August 10, 1995 12 working draft SCSI-3 Architecture Model 3.1 Glossary 3.1.1 aborted command : An SCSI command that has been ended by aborting the task created to execute it. 3 . 1 .2 ACA command : A command performed by a task with the ACA attribute \(see subclause 3.3 and objec t definition 6 \ 3.1.3 application client : An object that is the source of SCSI commands. 3 . 1 . 4 a uto contingent allegiance : The condition of a task set following the return of a CHECK CONDITION o r COMMAND TERMINATED status. 3.1.5 blocked \(task state\ : The state of a task that is prevented from completing due to an ACA condition. 3 . 1 . 6 b l o c k i n g b o u n d a r y : A task set boundary denoting a set of conditions that inhibit tasks outside the boundary from entering the Enabled state. 3.1.7 byte : An 8-bit construct. 3.1.8 call : The act of invoking a procedure. 3 . 1 . 9 c l i e n t - s e r v e r : A r e l a t i o n s h i p e s t a b l i s h e d b e t w e e n a p air of distributed objects where one \(the client\ the other \(the server\ 3.1.10 client : An object that requests a service from a server. 3.1.11 command : A request describing a unit of work to be performed by a device server. 3 . 1 . 1 2 c o m m a n d d escriptor block : A structure up to 16 bytes in length used to communicate a command from an application client to a device server. 3 . 1 . 1 3 c o m p l e ted command : A command that has ended by returning a status and service response of Tas k Complete, Linked Command Complete , or Linked Command Complete \(with flag\ . 3 . 1 . 1 4 c o m p l e t e d t a s k : A t a s k t h a t h a s e n d e d b y r e t u r n i n g a s t a t u s a n d service response of Task Complete . The actual events comprising the Task Complete response are protocol specific. 3.1.15 confirmation : A response returned to an object, which signals the completion of a service request. 3 . 1 . 1 6 confirmed protocol service : A service available at the protocol service interface, which require s confirmation of completion. 3.1.17 current task : A task that is in the process of sending status or transferring command data to or from the initiator. 3 . 1 . 18 destination device : The SCSI device to which a service delivery transaction is addressed. See sourc e device. 3 . 1 .19 device server : An object within the logical unit which executes SCSI tasks according to the rules for task management described in clause 7. 3 . 1 .20 device service request : A request, submitted by an application client, conveying an SCSI command to a device server. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 13 3 . 1 . 2 1 d e v i c e s e r v i c e r e s p o n s e : T h e r e sponse returned to an application client by a device server on completion of an SCSI command. 3 . 1 . 2 2 domain : An I/O system consisting of a set of SCSI devices that interact with one another by means of a service delivery subsystem. 3 . 1 . 2 3 d ormant \(task state\ : The state of a task that is prevented from starting execution due to the presence of certain other tasks in the task set. 3.1.24 enabled \(task state\ : The state of a task that may complete at any time. Alternatively, the state of a task that is waiting to receive the next command in a series of linked commands. 3.1.25 ended command : A command that has completed or aborted. 3 . 1 . 2 6 f a u l t e d initiator : The initiator to which a COMMAND TERMINATED or CHECK CONDITION status wa s returned. 3.1.27 faulted task set : A task set that contained a faulting task. 3 . 1 . 2 8 f a ulting command : A command that completed with a status of CHECK CONDITION o r COMMAND TERMINATED. 3 . 1 . 2 9 f a u l t i n g t a s k : A t a s k t h a t h a s c o m p l e t e d w i t h a s t a t u s o f C H E C K C O N D I TION or COMMAND TERMINATED. 3 . 1 . 3 0 f u n c tion complete : A logical unit response indicating that a task management function has finished. The actual events comprising this response are protocol specific. 3 . 1 . 3 1 h a r d reset : A target response to a reset event or a TARGET RESET in which the target performs th e operations described in subclause 5.6.6. 3 . 1 . 3 2 I / O o p e r a t i o n : A n operation defined by an unlinked SCSI command, a series of linked SCSI commands or a task management function. 3.1.33 implementation : The physical realization of an object. 3 . 1 . 3 4 implementation-specific : A requirement or feature that is defined in an SCSI-3 standard but whos e implementation may be specified by the system integrator or vendor. 3 . 1 . 3 5 i m p l e m entation option : An option whose actualization within an implementation is at the discretion of the implementor. 3 . 1 . 3 6 i n i t i a t o r : A n S C S I d e v i c e c o n t a i n i n g a p p l i c a t i o n c l i e n t s w h i c h o r i g i n a te device service and task management requests to be processed by a target SCSI device. 3 . 1 . 37 interconnect subsystem : One or more physical interconnects which appear as a single path for th e transfer of information between SCSI devices in a domain. 3.1.38 in transit : Information that has been sent to a remote object but not yet received. 3.1.39 layer : A subdivision of the architecture constituted by subsystems of the same rank. 3.1.40 linked CDB : A CDB with the link bit in the control byte set to one. atend X3T10/994D revision 18 August 10, 1995 14 working draft SCSI-3 Architecture Model 3.1.41 linked command : One in a series of SCSI commands executed by a single task, which collectively make u p a d i s c r e t e I / O o p e r a t i o n . I n s u c h a s e r i e s , e a ch command has the same task identifier, and all, except the last, have the link bit in the CDB control byte set to one. 3 . 1 . 4 2 l o g i c a l u n i t : A t a r g e t - r e s i dent entity which implements a device model and executes SCSI commands sent by an application client. 3.1.43 logical unit number : A 64-bit identifier for a logical unit. 3 . 1 . 4 4 l o g i c a l u n i t o p t i o n : A n o p t i o n p e r t a i n i n g t o a l o g i c a l u n i t , w h o s e a c t u alization is at the discretion of the logical unit implementor. 3 . 1 . 4 5 l o w e r l e v e l p r o t o c o l : A p r o t o c o l u s e d t o c a r r y t h e i n f o r m a t i o n r e p r e s enting upper level protocol transactions. 3.1.46 mandatory : The referenced item is required to claim compliance with a standard. 3 . 1 . 4 7 m e d i a i n f o r m a t i o n : I n f o r m a t i o n s t o r e d w i t h i n a n S C S I d e v i c e , w h i c h i s non-volatile \(retained through a power cycle\ 3 . 1 . 4 8 object : An architectural abstraction or "container" that encapsulates data types, services, or other objects that are related in some way. 3 . 1 . 4 9 o p t i o n , o p t i o n a l : I m p l e m e n t a t i o n o f t h e r e f erenced item is not required to claim compliance with an SCSI-3 standard. The implementation of an optional item shall comply with the standard. 3 . 1 . 5 0 peer-to-peer protocol service : A service used by an upper level protocol implementation to exchang e information with its peer. 3.1.51 peer entities : Entities within the same layer. 3.1.52 pending task : A task that is not a current task. 3 . 1 . 5 3 p h y sical interconnect : A single physical pathway for the transfer of information between SCSI devices in a domain. 3.1.54 port : Synonymous with "service delivery port". 3.1.55 procedure : An operation that can be invoked through an external calling interface. 3 . 1 . 5 6 p r o t o c o l - s p e c i f i c : I m p lementation of the referenced item is defined by an SCSI-3 protocol standard \( see 1.3.3\ 3 . 1 . 5 7 p r o t o c o l : T h e r u l e s g o v e r n i n g t h e c o n t e n t a n d exchange of information passed between distributed objects through the service delivery subsystem. 3.1.58 protocol option : An option whose definition within an SCSI-3 protocol standard is discretionary. | 3 . 1 . 5 9 p r o t o c o l s e r v i c e c o n f i r m a t i o n : A s i g n a l f r o m t h e l ower level protocol service layer notifying the upper layer that a protocol service request has completed. 3.1.60 protocol service indication : A signal from the lower level protocol service layer notifying the upper level that a protocol transaction has occurred. 3 . 1 . 6 1 p r otocol service request : A call to the lower level protocol service layer to begin a protocol servic e transaction. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 15 3.1.62 protocol service response : A reply from the upper level protocol layer in response to a protocol service indication. 3.1.63 queue : The arrangement of tasks within a task set, usually according to the temporal order in which they were created. See "task set". 3.1.64 receiver : A client or server that is the recipient of a service delivery transaction. 3 . 1 . 6 5 r e f e r e n c e m o d e l : A s t a n d a r d m o d e l u s e d t o s p e c i f y s y s t e m r e q u irements in an implementation-independent manner. 3.1.66 request : A transaction invoking a service. 3 . 1 . 6 7 r e q u e s t - r e s p o n s e t r a n s a c t i o n : A n i n t e r a c t i o n b e tween a pair of distributed, cooperating objects, consisting of a request for service submitted to an object followed by a response conveying the result. 3.1.68 request-confirmation transaction : An interaction between a pair of cooperating objects, consisting of a r e q u e s t f o r s e rvice submitted to an object followed by a response from the object confirming request completion. 3 . 1 . 6 9 r e s e r v e d : The term used for bits, fields, signals, and code values that are set aside for futur e standardization. 3 . 1 . 7 0 r e s e t e v e nt : A protocol-specific event which may trigger a hard reset response from an SCSI device a s described in subclause 5.6.6. 3.1.71 response : A transaction conveying the result of a request. 3.1.72 SCSI application layer : The protocols and procedures that implement SCSI commands and tas k management functions by invoking services provided by an SCSI protocol layer. 3 . 1 . 7 3 S C S I D e v i c e : A d e v i ce that is connected to a service delivery subsystem and supports an SCSI application protocol. 3.1.74 SCSI device identifier : An address by which an SCSI device is referenced within a domain. 3 . 1 . 7 5 S C S I I / O s y s t e m : A n I / O s y s t e m , c o n s i s t i n g o f t w o o r m o r e S C SI devices, an SCSI interconnect and an SCSI protocol, which collectively interact to perform SCSI I/O operations. 3 . 1 . 7 6 SCSI protocol layer : The protocol and services used by an SCSI application layer to transport dat a representing an SCSI application protocol transaction. 3.1.77 sender : A client or server that originates a service delivery transaction. 3.1.78 server : An SCSI object that performs a service on behalf of a client. 3 . 1 . 7 9 service : Any operation or function performed by an SCSI-3 object, which can be invoked by other SCSI-3 objects. 3 . 1 . 8 0 s ervice delivery failure : Any non-recoverable error causing the corruption or loss of one or more service delivery transactions while in transit. 3 . 1 . 8 1 s ervice delivery port : a device-resident interface used by the application client, device server or tas k m a n a g e r t o enter and retrieve requests and responses from the service delivery subsystem. Synonymous wit h "port". atend X3T10/994D revision 18 August 10, 1995 16 working draft SCSI-3 Architecture Model 3 . 1 . 8 2 s e r v i c e d e l i v e r y s u b s y s t e m : T h a t p a r t o f a n S C S I I / O s y stem which transmits service requests to a logical unit or target and returns logical unit or target responses to an initiator. 3.1.83 service delivery transaction : A request or response sent through the service delivery subsystem. 3 . 1 . 8 4 s i g n a l : \( n \ A d e t e c t a b l e a s y n c h r o nous event possibly accompanied by descriptive data and parameters. \(v\ The act of generating such an event. 3 . 1 . 8 5 s o urce device : The SCSI device from which a service delivery transaction originates. See destinatio n device. 3 . 1 . 8 6 s u b s y s t e m : A n e l e m ent in a hierarchically partitioned system which interacts directly only with elements in the next higher division or the next lower division of that system. 3 . 1 . 8 7 s u s p e nded information : Information stored within a logical unit that is not available to any pending tasks. 3 . 1 . 8 8 t a r g e t : A n S C S I d e v i c e w h i c h r e c e i v e s S C S I c o mmands and directs such commands to one or more logical units for execution. 3 . 1 . 8 9 t a s k : A n object within the logical unit representing the work associated with a command or group of linked commands. 3 . 1 .90 task abort event : An event or condition indicating that the task has been aborted by means of a tas k management function. 3 . 1 . 9 1 t a s k c o m p l e t i o n e v e n t : A n e vent or condition indicating that the task has ended with a service response of Task Complete . 3.1.92 task ended event : An event or condition indicating that the task has completed or aborted. 3 . 1 . 9 3 t a s k m a n a g e m e n t f u n c t i o n : A t a s k m a n a g e r s e r v i ce which can be invoked by an application client to affect the execution of one or more tasks. 3 . 1 . 9 4 t a s k management request : A request submitted by an application client, invoking a task managemen t function to be executed by a task manager. 3 . 1 . 9 5 t ask management response : The response returned to an application client by a task manager o n completion of a task management request. 3.1.96 task manager : A server within the target which executes task management functions. 3.1.97 task set : A group of tasks within a target device, whose interaction is dependent on the queuing and auto | contingent allegiance rules of clause 7. 3.1.98 task slot : Resources within the logical unit that may be used to contain a task. 3 . 1 . 9 9 t h i r d - p a r t y c o m mand : An SCSI command which requires a logical unit within the target device to assume the initiator role and send an SCSI command to a target device. 3 . 1 . 1 0 0 transaction : A cooperative interaction between two objects, involving the exchange of information or the execution of some service by one object on behalf of the other. 3 . 1 . 1 0 1 u n c o n f i r m e d p r o t o c o l s e r v i c e : A s e r v i c e available at the protocol service interface, which does not result in a completion confirmation. atend notation.wp August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 17 3.1.102 unlinked command : An SCSI-3 command having the link bit set to zero in the CDB control byte. 3 . 1 . 1 0 3 u p p e r l e v e l p r o t o c o l : A n a p p l i c a t i o n - s p e cific protocol executed through services provided by a lower level protocol. 3.1.104 vendor-specific : Specification of the referenced item is determined by the device vendor. atend X3T10/994D revision 18 August 10, 1995 18 working draft SCSI-3 Architecture Model 3.2 References to SCSI Standards T h e original Small Computer System Interface Standard, X3.131-1986, is referred to herein as SCSI-1. SCSI-1 w a s r e v i s e d r e s u l t i n g i n t h e S m a l l C o m p u t e r S y s t e m I n t e rface -2 \(X3.131-1994\ s e t o f S C S I - 3 s t a n d a r d s a r e c o l l e c t i v e l y r e f e r r e d t o a s S C S I - 3 . The term SCSI is used wherever it is not necessary to distinguish between the versions of SCSI. R e f e r e n c e s t o i n d i v i d u a l S C S I - 3 s t a n d a r d s within this document use one of the three-character mnemonics shown in 1.1. 3.3 Acronyms and Abbreviations: ACA : Auto contingent allegiance. AER: Asynchronous event report. CAM : Common Access Method. CDB : Command descriptor block. LLP: Lower level protocol. LUN : Logical unit number. SDP: service delivery port. SDS: Service Delivery Subsystem. ULP: Upper level protocol. 3.4 Editorial Conventions C e r t a i n w o r d s a n d t e r m s u s e d i n t h i s s t a n d a r d h a v e a s p e c i f i c m e a n i n g b e y o nd the normal English meaning. These words and terms are defined either in the glossary or in the text where they first appear. U p p e r c a s e i s u s e d w h e n r e f e r r i n g t o t h e name of a numeric value defined in this specification or a formal attribute p o s s e s s e d b y a n o b j e c t . When necessary for clarity, names of objects, procedures, parameters or discrete states are capitalized or set in bold type. 3.5 Numeric Conventions D i g i t s 0 - 9 i n t h e t e x t o f t h i s s t a n d a r d that are not immediately followed by lower-case "b" or "h" are decimal values. D i g i t s 0 a n d 1 i m m e d i a t e l y f o l l o w e d by lower case "b" are binary values. Digits 0-9 and the upper case letters "A"- "F" immediately followed by lower-case "h" are hexadecimal values. Large numbers are not separated by commas or spaces \(e.g., 12345; not 12,345 or 12 345\ atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 19 3.6 Reserved Fields and Codes R e s e r v e d f i e l d s a n d c o d e v a l u e s w i t h i n a d a t a s t r u c t u r e s p e c ified by this or any other SCSI-3 standard are set aside f o r f u t u r e standardization. Their use and interpretation may be specified by future extensions to these standards. A reserved field shall be set to zero, or in accordance with a future extension to any SCSI-3 standard. 3.7 Objects and Object Notation T h e S C S I a r c h i t e cture is defined in terms of objects. As specified in this standard, objects are abstraction s encapsulating a set of related functions, data types and other objects. Certain objects, such as an interconnect, m a y c o r r e s p o n d t o a p h y s i c a l e n t i t y w h i l e o t h e r s , s u c h a s a t a s k , m a y o n l y e x ist conceptually. That is, although such objects exhibit a well-defined, observable set of behaviors, they do not exist as separate physical elements. An object is a container that may enclose single entities and other objects. For example, an SCSI device may c o n t a i n l o g i c a l u n i t s . A l o g i c a l u n i t m a y h a v e t a s k s , a t a s k s e t a n d s o f o r t h. The following clauses describe notational and graphical conventions for specifying objects. 3.7.1 Notation for Objects The following symbols are used to define the composition of an object. = " i s c o m posed of" T h i s s y m b o l i n d i c a t e s t h a t t h e object named on the left is composed of the objects named of the right. + "together with" T h i s s y m b o l collects objects into a group. No ordering is implied. In the expression: A = B + C object A is composed of B together with C . [ | ] "select one of" This is equivalent to an "exclusive or" operation. In the expression: A = [B|C|D] object A is composed of one object selected from B , C or D . \(\ "optional" T h e o b j e c t s e n c l o s e d in parenthesis are optional. In the expression: A = B + \(C\ object A includes B and, optionally, C . atend X3T10/994D revision 18 August 10, 1995 20 working draft SCSI-3 Architecture Model { } "instances of" A s e t o f objects enclosed within curly brackets may occur an y n u m b e r o f t i m e s i n a g i v e n i n s tance. No physical ordering is implied. The brackets may be indexed. For example, M{...}N indicates an y number of instances from M to N. Thus: {...}3 implies 0, 1, 2 or 3 instances. 3{...} i m p l i e s 3 or more instances. The upper limit i s implementation or protocol specific. 3{...}3 implies exactly 3 instances. 3{...}5 implies from 3 to 5 instances. "xxx" ASCII characte r O b j e c t c o n s i s ts of the ASCII encodings for the characters enclosed string in quotation marks. nn binary encode d O b j e c t consists of the binary encoding representing the specifie d value value. For example A = 54 defines object A as the binary encoding of the decimal value 54. ... range Denotes a sequential set of discrete values. Thus: [1|...|100] implies one out of a set of binary encoded integer s between 1 and 100. ["A"|...|"Z"] implies one out of a set of ASCII-encoded alphabetic characters between "A" and "Z". Unless stated otherwise, literals outside the range of specifie d values are reserved for future standardization. 7 " p h y s i c a l l y As in A 7 B . Object A physically contains object B . contains" U s e o f t his notation is restricted to the specification of objec t addresses and identifiers as described below. vector of objects D e n o t e s " n n " p h y s i c a l l y c o n t i g u o u s i n s t a nces of the object. Thus, for example: byte<10> defines a physically contiguous vector of ten bytes. /*...*/ remark Encloses a comment. T h e r e i s n o p h y s i c a l o r d e r i n g implied by the sequence in which objects are specified in a grouping. Thus, the term "8{byte}8" or the expression " A + B + C " in an object definition says nothing about the physical ordering of these objects. A physically contiguous vector of items is denoted by means of the array notation specified above. Figure 3 : Example of Hierarchy Diagram 3.7.2 Object Addresses and Identifiers T h i s s t a n d a r d d e f i n e s c e r t a i n objects that are referenced externally by an address. By convention, such an object i s m a d e u p o f t w o components: a storage object specifying the maximum size of the address field and a set o f allowable identifier values. The following is an example of an identifier object definition. Ident_a = byte 7 [ 0 | ... | 243 ] The object "Ident_a" is an identifier composed of an 8-bit "container" \(the 'byte' object\ o f a single value from 0 to 243. Values not in the range are reserved. The left arrow operator \(" 7 "\ the storage object physically contains the encoding for one of the allowed values. 3.7.3 Predefined Objects The following predefined objects are used throughout this standard: Constant: Object containing a fixed value. The container size and contents ar e implementation-specific. Buffer = Byte : Byte array of size nn. Value: Numeric quantity. Flag = bit 7 7 [0|1]: A two-valued quantity as shown. 3.7.4 Hierarchy Diagrams H i erarchy diagrams show how objects are related to each other. The hierarchy diagram of figure 3, for example, shows the relationships among the objects comprising the "Book" object described in the following definition. Book = 1{Chapter} + \(Index\ Preface\ Chapter = 1{Section} + 0{Figure} Preface = 1{Introductory Text} + 0{Figure} atend X3T10/994D revision 18 August 10, 1995 22 working draft SCSI-3 Architecture Model A s g i v e n i n t h e o b j e c t d e f i nition, a Book object consists of one or more Chapters, a Table of Contents, an optional P r e f a c e a n d o p t i o n a l I n d e x . I n t h e c o r r e s p o n d i n g h i e r a rchy diagram, labeled boxes denote the above objects. The c o m p o s i t i o n a n d r e l a t i o n o f o n e o b j e c t t o others is shown by the connecting lines. In this case, the connecting lines indicate the relationship between "Book" and its constituent objects "Chapter", "Index", "Table of Contents" and \223Preface\224. Similarly, connecting lines show that "Chapter" contains objects "Section" and "Figure". Note that the Figure object may also be a component of Preface. T h e h i e r a r chy diagram does not show multiple instances of an object or the fact that certain objects are optional. I n t h i s e x a m p l e , t h e F i g u r e o b j e c t is shown only once, even though a chapter or preface may have several \(or no\ instances of this object. Similarly, the Index object is shown even though it too is optional. 3.8 Notation for Procedures and Functions I n t h i s s t a n d a r d , t h e m o d e l f o r f u n c t ional interfaces between objects is the callable procedure. Such interfaces are specified using the following notation: [Result = ] Procedure Name \([input-1] [,input-2] ...] || [output-1] [,output-2] ...\ Where: Result: A single value representing the outcome of the procedure or function. Procedure Name: A descriptive name for the function to be performed. "\(...\ Parentheses enclosing the lists of input and output arguments. Input-1, Input-2, ...: A c o m m a - separated list of names identifying caller-supplied input dat a objects. Output-1, Output-2, ...: A c o m ma-separated list of names identifying output data objects to b e returned by the procedure. "||": A s e p arator providing the demarcation between inputs and outputs. Input s are listed to the left of the separator; outputs are listed to the right. "[...]": Brackets enclosing optional or conditional parameters and arguments. The data objects are specified using the notation of 3.7.1. This notation allows any data objects to be specified as inputs and outputs. The following is an example of a procedure specification: Found = Search \(Pattern, Item List || [Item Found] \ Where: Found = Flag Flag , which, if set, indicates that a matching item was located. Input Arguments: Pattern = ... /* Definition of Pattern object */ Actions taken on entry to S0 Actions taken on entry to S1 E0: Condition for transition of S0 back to itself E0: Condition for transition of S1 to S0 E1: Condition for transition of S0 to S1 S0:S0 S0:S1 S1:S0 transition label The S0 entry actions are executed following this transition. August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 23 Figure 4 : State Diagram Object containing the search pattern. Item List = Item /* Array of NN Item objects*/ Contains the items to be searched for a match. Output Arguments: Item Found = Item ... /* Item located by the search procedure */ This object is only returned if the search succeeds. Predefined objects commonly used as arguments are defined in 3.7.3. 3.9 State Diagram All state diagrams use the notation shown in figure 4. A system specified in this manner has the following properties: a\ Time elapses only within discrete states. b\ State transitions are logically instantaneous. c\ Every time a state is entered, the actions of that state are started. Note that this means that a transition that points back to the same state will restart the actions from the beginning. atend archmod.wp X3T10/994D revision 18 August 10, 1995 24 working draft SCSI-3 Architecture Model 4 SCSI-3 Architecture Model 4.1 Introduction The purpose of the SCSI-3 architecture model is to: d\ P r o v i d e a b a s i s f o r t h e c o o r d i n a t i o n of SCSI-3 standards development which allows each standard to be placed into perspective within the overall SCSI-3 Architecture model. e\ I d e n t i f y a r e a s f o r d e v e l o p i n g s t a n d a r d s a n d p r ovide a common reference for maintaining consistency among related standards so that independent teams of experts may work productively and independently on the development of standards within each functional area. f\ P r o v i d e the foundation for application compatibility across all SCSI-3 interconnect and protocol environments b y specifying generic requirements that apply uniformly to all implementation standards within each functional area. T h e development of this standard is assisted by the use of an abstract model. To specify the external behavior of a rea l S C S I - 3 system, elements in a real system are replaced by functionally equivalent components within this model. Onl y e x t e r n a l l y o b s e r v a b l e b e h a v i o r is retained as the standard of behavior. The description of internal behavior in this standard i s p r o v ided only to support the definition of the observable aspects of the model. Those aspects are limited to the generic p r o p e r t i e s a n d c h a r a c t e r i stics needed for host applications to interoperate with SCSI-3 devices in any SCSI-3 interconnect and protocol environment. As such, the model does not address other requirements which may be essential to some I/O s y s tem implementations such as the mapping from SCSI device addresses to network addresses, the procedure fo r d i s c o v e r i n g S C S I - 3 d evices on a network and the definition of network authentication policies for SCSI initiators or targets. These considerations are outside the scope of the architecture model. T h e r e a d e r n o t f a m i l i a r w i t h t h e c o n c ept of abstract modeling is cautioned that concepts introduced in the description of an SCSI-3 I/O system constitute an abstraction despite a similar appearance to concepts possibly found in real systems . Therefore, a real SCSI-3 I/O system need not be implemented as described by the model. Such a system, regardless of how it is implemented, shall, however, comply with the requirements of this and all other applicable standards. The SCSI-3 architecture model is described in terms of objects, protocol layers and service interfaces between objects. A s d i s c u s s e d i n 3 . 7 , a n o b j e c t may be a single numeric parameter, such as a logical unit number, or a complex entity that performs a set of operations or services on behalf of another object. S e r v i c e i n t e r faces are defined between distributed objects and protocol layers. The template for a distributed servic e i n t e r f a c e i s t h e c l i e n t - s e r v e r m o d e l d e s c r i b e d i n 4 . 2 . S u b c l a u s e 4 . 4 specifies the structure of an SCSI I/O system by defining the relationship among objects. The set of distributed services to be provided are specified in clauses 5 and 6. R e q u i r e m ents &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& that apply to each SCSI-3 protocol standard are specified in the protocol service model described i n s u b c l a u s e s 5 . 3 a n d 6 . 7 . T h e m o d e l d e s c r i b e s r e q u i r e d b e h a v i o r i n t e r m s o f l a y e r s, objects within layers and protocol service transactions between layers. 4.2 The SCSI-3 Distributed Service Model S e r v ice interfaces between distributed objects are represented by the client-server model shown in figure 5. Dashe d h o r i z o n t a l arrows denote a single request-response transaction as it appears to the client and server. The solid arrow s i n d i c a t e t h e a c t u a l t r a n s a c t i o n p a t h t h r o u g h t h e s e r v i c e d e l i v e r y subsystem. In such a model, each client or server is a single thread of execution which runs concurrently with all other clients or servers. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Client Server Server Request Server Response Client-Server T ransaction Service Delivery Subsystem Protocol Service Interface August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 25 Figure 5 : Client-Server Model A c l i e nt-server transaction is represented as a remote procedure call with inputs supplied by the caller \(the client\ Th e p r o c e d u r e e x e c u t e d by the server returns outputs and a procedure status. A client directs requests to a remote server, via t h e client's service delivery subsystem, and receives a completion response or a failure notification. The request, whic h i d e n t i fies the server and the service to be performed, includes the input data. The response conveys the output data and r e q u e s t s t a t u s . T h e f u n c t ion of the service delivery subsystem is to transport an error-free copy of the request or response b e t w e e n s e n d e r a n d r e c e i v e r . A f a i l u r e n o t i f i c a t i o n i n d i c a t e s t h a t a condition has been detected, such as a reset, or service delivery failure, that precludes request completion. A s s e e n b y t h e c l i e n t , a r e q u e s t b e c o m e s p e n d i n g w h e n it is passed to the service delivery subsystem for transmission. The r e q u e s t i s c o m p l e t e w h e n t h e server response is received or when a failure notification is returned. As seen by the server, t h e r e q u e s t b e comes pending upon receipt and completes when the response is passed to its service delivery subsystem for return to the client. As a result there will usually be a time skew between the server and client's perception of request status and logical unit state. All allusions to a pending command or task management function in this standard are in the application client's frame of reference. C l i e n t - s e r v e r r e l a t i o n s h i p s a r e n o t s y m m e trical. A client may only originate requests for service. A server may only respond t o s u c h r e q u e s t s . T h e c l i ent calls the server-resident procedure and waits for completion. From the client's standpoint, the b e h a v i o r o f a r e m o t e service invoked in this manner is indistinguishable from a conventional procedure call. In this model, c o n f i rmation of successful request or response delivery by the sender is not required. The model assumes that deliver y failures will be detected by the client's service delivery port. 4.3 The SCSI-3 Client-Server Model A s s h o w n i n f i g u r e 6 , e a c h S C S I - 3 t a r g e t d e v i c e p r o v i d e s t w o c l a s s e s o f s e r v i c e , device services executed by the logical units u n d e r t h e c o n t r o l o f t h e t a r g et and task management functions performed by the task manager. A logical unit is an object that implements one of the device functional models described in the SCSI-3 command standards and executes SCSI-3 commands such as reading from or writing to the media. Each pending SCSI command or series of linked commands d e fines a unit of work to be performed by the logical unit. As described below, each unit of work is represented within the target by a task which can be externally referenced and controlled through requests issued to the task manager. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Application Client T ask Manager Initiator T arget Device Service Request T ask Management Req. Device Service Response T ask Management Resp. Logical Unit Device Server X3T10/994D revision 18 August 10, 1995 26 working draft SCSI-3 Architecture Model Figure 6 : SCSI Client-Server Model All requests originate from application clients residing within an initiator device. An application client represents a thread o f e x e c u t i o n w h o s e f u n c t i o n ality is independent of the interconnect and SCSI-3 protocol. In an implementation, that thread c o u l d correspond to the device driver and any other code within the operating system that is capable of managing I/ O r e q u e s t s w i t h o u t r e q u i r i n g k n o w l e d g e o f t h e i n t e r c o n n e c t or SCSI-3 protocol. In the architecture model, an application client i s created to issue a single SCSI-3 command or task management function; it ceases to exist once the command or task m a n a g e m e n t f u n c t i o n e n d s . C o n s e q u e n t l y , t h e r e i s o n e a p p l i c a tion client for each pending command or task management r e q u e s t . W i t h i n t h e i n i t i a t o r , o n e o r m o r e c o n t r o lling entities, whose definition is outside the scope of the architecture model, oversee the creation of and interaction among application clients. A s d e s c r i b e d i n 4 . 2 , e a c h r e q u e s t t a k e s t h e f o r m o f a p r o c e d u r e c a l l w i t h a r g u m e n ts and a status to be returned. An SCSI-3 c o m m a nd is issued as a request for device service directed to a device server within a logical unit. Each device servic e r e q u e s t c o n t a i n s a c o m m a n d d e s c r i p t o r b l o c k , d e f i n i n g t h e o p e r a t i o n to be performed, along with a list of command-specific inputs and other parameters specifying how the command is to be processed. If supported by a logical unit, a sequence of linked commands may be used to define an extended I/O operation. A t a s k i s a n o b j e c t w i t h in the logical unit representing the work associated with a command or series of linked commands. A n e w c o m m a n d o r t h e f i r s t i n a s e r i e s o f l i n k e d c o m m a n d s c a u s e s t h e c r e a t i o n o f a task. The task persists until a command c o mpletion response is sent or until the task is ended by a task management function or exception condition. Subclause 5.5.1 gives an example of the processing for a single command. Subclause 5.5.2 gives an example of linked comman d processing. A n a p p l i c a t i o n c l i e n t m a y r e q u e s t e x e c u t i o n o f a t a s k m a n a g e m e nt function through a request directed to the task manager. S u b c l a u s e 6 . 8 s h o w s t h e i n t e r a c tions between the task manager and application client when a task management request is processed. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Power Power Power Power DA T A DA T A DA T A DA T A SCSI Device SCSI Device SCSI Device SCSI Device Service Delivery Subsystem I/O System Domain August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 27 Figure 7 : SCSI I/O System and Domain Model 4.4 The SCSI-3 Structural Model T h is clause uses the notation for hierarchy diagrams of 3.7.4 and the object notation specified in 3.7.1 to formally define t h e s t r u c t u r e o f an SCSI-3 I/O system as seen by an application client. Certain object definitions may include one or more n u m e r i c p a r a m e t e r s d e f i n i n g a n a l l o w a b l e r a n g e f o r a d d r e s s e s o r identifiers. The range of addresses or identifiers that shall b e s u pported by an SCSI-3 protocol implementation shall be defined in the SCSI-3 protocol standard that applies to that i m p l e m e n t a t i o n . S u c h o b j e c t s , h o w e ver, shall not exceed the values specified in this standard. In addition, unless specified o t h e r w i s e i n t h i s s t a n d a r d , a n a d d r e s s o r i d e n t i f i e r supported by an SCSI-3 protocol may be less than the maximum defined herein. To ensure compatibility with any SCSI-3 protocol, the protocol-independent portions of a system implementation should be designed to use the address or identifier specifications as they appear in this standard. T h e S C S I - 3 s t r u c t u r a l m o d e l r e p r e s e n t s a v i e w o f t h e e l e m e n t s c o mprising an SCSI-3 I/O system as seen by the application clients interacting with the system through the service delivery port. In an implementation, this view is similar to that seen b y a CAM device driver interacting with the system through the CAM SIM layer. This model is defined as a hierarchy o f o b j e c t s . As shown in figure 7, the fundamental object is the SCSI domain, which represents an I/O system. A domain i s m a d e u p o f S C S I d e v i c e s a n d a s e r v i c e d e l i v e r y s u b s y s t e m , w h i c h transports commands and data. An SCSI device, in turn, may consist of logical units and so forth. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Domain Service Delivery Subsystem Service Delivery Port Interconnect Subsystem SCSI Device Initiator Application Client T arget Logical Unit T ask Manager T ask Set \050Queue\051 Device Server c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE SCSI Device SCSI Device SCSI Device SCSI Device Service Delivery Port Service Delivery Port Service Delivery Port Service Delivery Port Service Delivery Subsystem X3T10/994D revision 18 August 10, 1995 28 working draft SCSI-3 Architecture Model Figure 8 : SCSI Hierarchy Figure 9 : Domain Functional Model F i g u r e 8 s h o w s t h e m a i n functional components of the SCSI hierarchy. The following clauses define these components in greater detail using the conventions of 3.7. 4.5 SCSI Domain atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE SCSI Domain Service Delivery Subsystem SCSI Device August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 29 Figure 10 : Domain Hierarchy Object Definition 1 SCSI Domain SCSI Domain = 2{SCSI Device} + Service Delivery Subsystem Object Descriptions: SCSI Device: A d e v i c e t h a t o r i g i n a t e s o r services SCSI-3 commands. As described in 4.7, a n S CSI-3 device originating a command is called an initiator; a devic e containing logical units that service commands is called a target. Service Delivery Subsystem through which clients and servers communicate \(see 4.6\ Subsystem: T h e d o m a i n b o u n d a r i e s a r e e s t a b l i s h e d b y t h e s y s t e m i m p l e mentor, within the constraints of a specific SCSI-3 protocol and interconnect standard. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Service Delivery Subsystem Service Delivery Port Interconnect Subsystem X3T10/994D revision 18 August 10, 1995 30 working draft SCSI-3 Architecture Model Figure 11 : Service Delivery Subsystem Hierarchy Object Definition 2 : Service Delivery Subsystem 4.6 The Service Delivery Subsystem Service Delivery Subsystem = 2{Service Delivery Port} + Interconnect Subsystem Object Descriptions: Service Delivery Port: D e v i ce-resident component of the service delivery subsystem \(see objec t d e f i n i t i o n 3 \ . T h i s o b j e c t m a y c o n t a i n h a r d w a re and software that implements the protocols and interface to the interconnect subsystem. Interconnect Subsystem: A s e t o f o n e or more physical interconnects that appear to a client or server as a single path for the transfer of data between SCSI devices. T h e service delivery subsystem is assumed to provide error-free transmission of requests and response s b e t w e e n c l i e n t a n d s e r v e r . A l t h o u g h a device driver in an SCSI-3 implementation may perform these transfers t h r o u g h s e v e r a l i n t e r a c t i o n s w i t h i t s S C S I - 3 p r o t o c o l l a y e r , t h e architecture model portrays each operation, from t h e v i e w p o i n t of the application client, as occurring in one discrete step. In this model, the data comprising an o u t g o i n g request is sent in a single "package" containing all the information required to execute the remot e p r o c e d u r e c a l l . S i m i l a r l y , a n i n c o ming server response is returned in a package enclosing the output data and s t a t u s . T he request or response package is "sent" when it is passed to the service delivery port fo r t r a n s m i s s i o n ; i t i s " i n transit" until delivered and "received" when it has been forwarded to the receiver via the destination device's service delivery port. 4.6.1 Synchronizing Client and Server States T h e c l ient is usually informed of changes in server state through the arrival of server responses. In th e a r c h i t e c t u re model such state changes occur after the server has sent the associated response and possibly b e f o r e t h e r e s p o n s e h a s b e e n r e c e i v e d b y t h e i n i t i a t o r . S o m e S C S I - 3 p r o t o cols, however, may require the target to verify that the response has been received successfully before completing a state change. State changes c o n t r o l l e d i n t h i s manner are said to be synchronized. Since synchronized state changes are not assumed or r e q u i r e d b y t h e architecture model, there may be a time lag between the occurrence of a state change within the target and the initiator\222s awareness of that change. T h e m o d e l a s s u m e s t h a t s t a te synchronization, if required by an SCSI-3 protocol standard, is enforced by the s e r v i c e d e l i v e r y s u b s y s t e m t r a n s p a rently to the server. That is, whenever the server invokes a protocol service to return a response as described in subclauses 6.7 and 5.3, it is assumed that the service delivery port for atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 31 such a protocol will not return control to the server until the response has been successfully delivered to the initiator. 4.6.2 Request/Response Ordering I n this standard, request or response transactions are said to be in order if, relative to a given pair of sending and receiving devices, transactions are delivered in the order they were sent. A s e n d e r m a y occasionally require control over the order in which its requests or responses are presented to t h e r e c e i v e r . F o r e x a m p l e , t h e s e q u e n c e i n w h i c h r e q u e sts are received is often important whenever an initiator issues a series of SCSI-3 commands with the ORDERED attribute to a logical unit as described in clause 7. In this case, the order in which these commands are completed, and hence the final state of the logical unit, m a y d e p e n d o n the order in which these commands are received. Similarly, the initiator acquires knowledge a b o u t t h e state of pending commands and task management functions and may subsequently take actio n b a s e d o n t h e n a t u r e a n d s e q u e n c e o f t a r g e t responses. For example, if the initiator aborts a command whose c o m p l e t i o n r e s p o n s e is in transit and the abort response is received out of order, the initiator could incorrectly conclude that no further responses are expected from that command. T h e m a n n e r i n w h i c h o r d e r ing constraints are established is implementation-specific. An implementation may c h o o s e t o d elegate this responsibility to the application client \(e.g., the device driver\ or the service deliver y p o r t . I n s o m e c a s e s , i n - o r d e r d e l i v e r y may be an intrinsic property of the transport subsystem or a requirement established by the SCSI-3 protocol standard. For convenience, the SCSI-3 architecture model assumes in-order delivery to be a property of the servic e d e l i v e r y s u b s y s t e m . This assumption is made to simplify the description of behavior and does not constitute a r e q u i r e m e n t . In addition, this specification makes no assumption about, or places any requirement on th e ordering of requests or responses between one sending device and several receiving devices. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Service Delivery P ort SC SI Device Logical Unit Service Delivery Subsystem T arget Model SC SI Device Initiator Model Applica- tion Client Initiator SC SI Device T arget Logical Unit Combined Model Applica- tion Client Service Delivery Subsystem Service Delivery P ort Service Delivery P ort Service Delivery Subsystem c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE SC SI Device Initiator T arget Service Delivery P ort X3T10/994D revision 18 August 10, 1995 32 working draft SCSI-3 Architecture Model Figure 12 : SCSI Device Functional Models Figure 13 : SCSI Device Hierarchy Diagram Object Definition 3 : SCSI Device 4.7 SCSI Device Models F i gure 12 shows the functional models for SCSI devices that can perform only target or initiator functions or a r e c a p a b l e o f s u p p o r t i n g b o t h f u n c t i o n s . T h e d e f i n i t i o n a n d h i e r a r c h y a re shown in object definition 3 and figure 13. SCSI Device = [Initiator | Target | Target + Initiator] + 1{Service Delivery Port} Service Delivery Port = Implementation-specific hardware and software atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 33 Object Definition 4 : Initiator Object Descriptions: Initiator: A n S C S I - 3 d e v i c e w h i c h i s c a p a b l e o f o r i g i n a t i n g SCSI-3 commands and task management requests \(see 4.7.1\ Target: A n S C S I - 3 d e v i c e w h i c h i s c a p a b l e o f executing SCSI-3 commands and task management requests \(see 4.7.2\ Service Delivery Port: D e v i c e - r e s i d e n t c o m p o n e n t o f t h e S e r v i c e D e l i very Subsystem containing the h a r d w a r e and software needed to implement an SCSI-3 protocol and a n interface to the interconnect subsystem \(see object definition 2\ A device is referred to by its role when it participates in an I/O operation. That is, such a device is called a target w h e n i t e x e cutes an SCSI-3 command or task management function and an initiator when it issues an SCSI- 3 command or task management request. The following sections formally define the target and initiator device models. 4.7.1 SCSI Initiator Model Initiator = 0{Application Client} Object Descriptions: Application Client: S o u rce of commands and task management functions. There is on e a p p l i c a t i o n c l i e n t f o r e a c h p e n d ing command or task management function. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Logical Unit T arget T arget Identifier T ask Manager X3T10/994D revision 18 August 10, 1995 34 working draft SCSI-3 Architecture Model Figure 14 : Target Object Hierarchy Object Definition 5 : Target 4.7.2 SCSI Target Target = 0{Logical Unit} + Logical Unit 0 + 1{Target Identifier} + Task Manager Target Identifier = bit<64> 7 7 [0|...|2 -1] 64 Object Descriptions: Target Identifier: 64 bits identifying the target device. A s i m p l i e d b y o b j e c t d e f i n i t i o n 5 above, a target device may respond to more than one target identifier. Each target identifier shall be unique within th e scope of the domain. The set of identifiers by which a target device i s referenced shall be the same for every initiator in the domain. Task Manager: S e r v e r t h a t controls one or more tasks in response to task managemen t requests. Logical Unit: Object to which SCSI-3 device commands are directed. Logical Unit 0: A logical unit whose logical unit number is zero \(see 4.7.4\ 4.7.3 The Task Manager The task manager controls the execution of one or more tasks by servicing the task management functions s p e c i f i e d i n c l a u s e 6 . I t s e x t e r n a l a d d r e s s i s e q u a l t o t h e t a r g e t identifier. As specified in object definition 5, there is one task manager per target device. T h e o r d e r i n w h i c h t a s k m a n a g e m e n t r e q u ests are executed is not specified by this standard. In particular, this s t a n d a r d d o e s n o t require in-order delivery of such requests, as defined in 4.6.2, or execution by the tas k m a n a g e r i n t h e o r der received. To guarantee the execution order of task management requests directed to a s p e c i f i c l o g i c a l u n i t , a n i n i t i a tor should, therefore, not have more than one such request pending to that logical unit. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Logical Unit Device Server Logical Unit Number T ask Set T agged T ask Untagged T ask August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 35 Figure 15 : Logical Unit Object Hierarchy Object definition 6 : Logical Unit 4.7.4 Logical Unit Logical Unit = Device server + Logical Unit Number + Task Set Logical Unit Number = bit<64> 7 7 [0|...|2 -1] 64 Logical Unit Identifier = Target Identifier + Logical Unit Number Task Set = [0{Tagged Task} + 0{Untagged Task} | 0{Untagged Task} ] Object Descriptions: Device Server: O b j e c t t h a t e x ecutes SCSI commands and manages the task set according to the rules defined in clause 7. Task Set : A s e t o f t asks whose interaction is determined by the rules for task se t m a n a g e m e n t specified in clause 7 and the auto contingent allegiance rules specified in subclause 5.6.1. Tagged task: A t a s k w hose identifier includes an initiator-specified component \(tag\ an d one of the task attributes specified in object definition 7. Untagged task: A t ask whose identifier does not include a tag component \(see objec t definition 7\ Logical Unit Number: An encoded identifier for the logical unit. Logical Unit Identifier: External identifier used by an initiator to reference the logical unit. atend X3T10/994D revision 18 August 10, 1995 36 working draft SCSI-3 Architecture Model Object Definition 7 : Task Task = [ Tagged Task | Untagged Task ] Tagged Task = Tagged Task Identifier + Task Attribute Untagged Task = Untagged Task Identifier + SIMPLE Tag = bit<64> 7 7 [0|...|2 -1] 64 Task Attribute = [SIMPLE | ORDERED | HEAD OF QUEUE| ACA ] Task Identifier = [ Untagged Task Identifier | Tagged Task Identifier ] Tagged Task Identifier = Initiator Identifier + Logical Unit Identifier + Tag Untagged Task Identifier = Initiator Identifier + Logical Unit Identifier Task Address = [Untagged Task Address | Tagged Task Address] Tagged Task Address = Logical Unit Identifier + Tag Untagged Task Address = Logical Unit Identifier Initiator Identifier = bit<64> 7 7 [0|...|2 -1] 64 Object Descriptions: Tag: 64-bit identifier assigned by the initiator. Initiator Identifier: P r o t o c o l - s p e c i f i c i d e n t i f i e r o f t h e initiator from which the command originated \(see 4.7.1\ Logical Unit Identifier: Logical unit identifier as defined in object definition 6. Task Attribute: One of the attributes described in subclause 7.5 Task Address: The address used by an application client to reference a task. Tagged Task Address: T h e a d d r e s s u s e d b y a n application client to reference a tagged task. When u s e d a s a n a r g u m e n t i n a d e v i c e s e r v e r o r task manager request, the service d e livery subsystem will convert this parameter to a tagged task identifie r before passing it to the server. Untagged Task T h e a d dress used by an application client to reference an untagged task . Address: W h e n u s e d a s a n a r g u m e nt in a device server or task manager request, the service delivery subsystem will convert this parameter to an untagged task identifier before passing it to the server. E v e r y S C S I -3 protocol shall support tagged and untagged tasks. Support for the creation of tagged tasks by a logical unit, however, is a logical unit implementation option. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 37 A t a s k i d e n t i f i e r t h a t i s i n u s e s h a l l b e u n i q u e a s s e e n b y t h e i n i t i a t o r o r i g inating the command and the target to which t h e c o m m a n d w a s addressed. \(A task identifier is in use over the interval bounded by the events specified in 5.4\ A t a s k i dentifier is unique if one or more of its components is unique within the scope specified above. B y i m p l i c a t ion, therefore, an initiator shall not cause the creation of more than one untagged task having identica l v a l u e s f o r t h e target and logical unit identifiers. Conversely, an initiator may create more than one task with th e same tag value, provided at least one of the remaining identifier components is unique. 4.8 The SCSI-3 Model for Distributed Communications T h e S C S I - 3 m o d e l f o r c o m m u n i c a t i o n s b e t w e e n d i s t r i b u t e d o b j e c t s i s b a s e d on the technique of layering. According t o t h i s t e c h n i q u e , t h e initiator and target I/O systems are viewed as being logically composed of the ordered set of subsystems represented for convenience by the vertical sequence shown in figure 16. T h e l a y e r s comprising this model and the specifications defining the functionality of each layer are denoted b y h o r i z o n t a l s e q u e n c e s . A l a y e r c o n s i s t s o f p e e r e n t i t i e s w h i c h c o m m u n i c a t e with one another by means of a protocol. E x c e p t f o r t h e p h y s i c a l interconnect layer, such communication is accomplished by invoking services provided by the adjacent lower layer. By convention, the layer from which a request for service originates is called the upper l e v e l p r o t ocol layer or ULP layer. The layer providing the service is referred to as the lower level protocol layer or LLP layer. The following layers are defined: a\ S C S I - 3 a p p l i c a t i o n l a y er : Contains the clients and servers that originate and execute SCSI-3 I/O operations by means of an SCSI-3 application protocol; b\ S C S I - 3 protocol layer : Consists of the services and protocols through which clients and server s communicate; c\ P h y s ical interconnect layer : Comprised of the services, signaling mechanism and interconnect subsystem needed for the physical transfer of data from sender to receiver. T h e s u b s y s t e m s t h a t m a k e u p t h e p r o t o c o l a n d i n t e r c o n n e c t l a y e r s a r e c o l l e c t i v ely referred to as the service delivery subsystem. The service delivery port is the device-resident portion of this system. T h e s et of protocol services implemented by the service delivery subsystem are intended to identify externa l b e h a v i o r a l r e q u i r e m e n t s that apply to SCSI-3 protocol specifications. While these protocol services may serve as a g u i d e f o r d e s i g n i n g reusable software or firmware that can be adapted to different SCSI-3 protocols, there is no requirement for an implementation to provide the service interfaces specified in this standard. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE SCSI-3 Application SCSI-3 Application SCSI-3 Protocol Services SCSI-3 Protocol Services Physical Interconnect Services Physical Interconnect Services Protocol Service Interface Physical Interconnect Service Interface Physical Interconnect SCSI Protocol SCSI-3 Application Protocol SAM SCSI-3 Application Layer SCSI-3 Protocol Layer Physical Interconnect Layer SCSI-3 Protocol Standard Physical Interconnect Standard Initiator I/O System T arget I/O System X3T10/994D revision 18 August 10, 1995 38 working draft SCSI-3 Architecture Model Figure 16 : Protocol Service Reference Model atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE LLP Layer ULP Layer Protocol Service Request Protocol Service Confirmation Protocol Service Indication Protocol Service Response August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 39 Figure 17 : Protocol Service Model A n i n t e r a c t i o n b e t w e e n l a y e r s c a n o r i g i n a t e f r o m a n e n t i t y w i t h i n t h e LLP or ULP layer. Such interactions are defined w i t h r e s p e c t to the ULP layer as outgoing or incoming interactions. An outgoing interaction takes the form of a p r o c e d u r e call invoking an LLP service. An incoming interaction appears as a signal sent by the LLP layer, which m a y b e a c c o m p anied by parameters and data. Both types of interaction are described using the notation fo r p r o c e d u r e s s p e c i f i e d i n 3 . 8 . I n t h i s m o d e l , i n p u t a r g u m e n ts are defined relative to the layer receiving an interaction. That is, an input is a parameter supplied to the receiving layer by the layer initiating the interaction. The following types of service interactions between layers are defined: a\ Protocol service request : A request from the ULP layer invoking some service provided by the LLP layer; b\ P r o t o c o l s e r v i c e i n d i c a t i o n : A s i g n al from the LLP layer informing the ULP layer that an asynchronous event has occurred, such as a reset or the receipt of a peer-to-peer protocol transaction; c\ P r o t o c o l s e r v i c e r e s p o n s e : A c a l l t o t h e L L P l a y e r invoked by the ULP layer in response to a protocol service indication. A protocol service response may be invoked to return a reply to the ULP peer; d\ P r o t ocol service confirmation : A signal from the LLP layer notifying the ULP layer that a protocol servic e request has completed. A confirmation may communicate parameters that indicate the completion status o f t h e protocol service request or any other status. A protocol service confirmation may be used to convey a response from the ULP peer. The services provided by an LLP layer are either confirmed or unconfirmed. A ULP service request invoking a confirmed service always results in a confirmation from the LLP layer. All four protocol service types are related as shown in the following diagram: atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Protocol Service Request Protocol Service Indication LLP Protocol T ransactions Protocol Service Response Protocol Service Confirmation LLP Protocol T ransactions Server Request Server Response LLP Layer ULP Layer Client Server Protocol Service Interface X3T10/994D revision 18 August 10, 1995 40 working draft SCSI-3 Architecture Model Figure 18 : Request-Response ULP Transaction and Related LLP Services F i g u r e 1 8 s h o w s h o w p r o t o c o l s e r v i c e s m a y b e used to execute a client-server request-response transaction at the SCSI application layer. T h e d a s h e d l i n e s s h o w a n S C S I a p p l i c a t i o n p r o t o c o l t r a n s a c t ion as it might appear to sending and receiving entities w i t h i n t h e c l i e n t a n d s e r v e r . T h e s o l i d l i n e s s h o w the corresponding protocol services and LLP transactions that are used to physically transport the data. atend procmod.wp August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 41 5 SCSI Command Model An application client invokes the following remote procedure to execute an SCSI command: Service response = Execute Command \(Task Address, CDB, [Task Attribute], [Data-Out Buffer], [Command Byte Count], [Autosense Request] || [Data-In Buffer], [Sense Data], Status\ Input Arguments: Task Address : See object definition 7. CDB : Command descriptor block \(see 5.1\ Task Attribute : A value specifying one of the task attributes defined in subclause 7.5. This a r g u m ent shall not be specified for an untagged command or the nex t command in a sequence of linked commands. \(Untagged tasks shal l i m p l i c i t ly have the SIMPLE attribute. The attribute of a task that execute s l i n k ed commands shall be set according to the Task Attribute argumen t specified for the first command in the sequence.\ Data-Out Buffer : A b u f fer containing command-specific information to be sent to the logica l unit, such as data or parameter lists needed to service the command. Command Byte Count : The maximum number of bytes to be transferred by the command. Autosense Request : A n a r g u m e n t r e q u e s t i n g t h e automatic return of sense data by means of the a u t o s e n s e mechanism specified in 5.6.4.2. It is not an error for th e a p p l i c a t i o n client to provide this argument when autosense is not supported by the SCSI-3 protocol or logical unit. Output Arguments: Data-In buffer : A buffer containing command-specific information returned by the logica l u n it on command completion. The application client shall not assume tha t t h e b u f f e r c o n t e n t s a r e v a l i d u n less the command completes with a status of G O O D , INTERMEDIATE, or INTERMEDIATE-CONDITION MET. Whil e some valid data may be present for other values of status, the applicatio n client will usually have to obtain additional information from the logical unit, such as sense data, to determine the state of the buffer contents. . Sense Data : A b u f f e r containing sense data returned by means of the autosens e mechanism \(see 5.6.4.2\ atend X3T10/994D revision 18 August 10, 1995 42 working draft SCSI-3 Architecture Model Status : A one-byte field containing command completion status \(see 5.2\ If th e c o m m a n d ends with a service response of Service Delivery o r T a r g e t F a i l u r e , t h e a p p l i c a t i o n client shall consider this parameter to be undefined. An SCSI-3 command shall not allow both the Data-In Buffer and the Data-Out Buffer arguments. Service Response assumes one of the following values: Task Complete : A l o g i c a l unit response indicating that the task has ended. The statu s p a r a m e t e r shall have one of the values specified in 5.2 other tha n INTERMEDIATE or INTERMEDIATE-CONDITION MET. Linked Command Complete : Linked Command Complete \(with flag\ : L o g i c a l unit responses indicating that a linked command has complete d s u c c e s s fully. As specified in 5.2, the status parameter shall have a value of I N T E R M E D I A T E o r I N T E R MEDIATE-CONDITION MET. A value of Linked C o m m a n d C o m p l e t e \( w i t h f l a g \ i n dicates that a linked command with the flag bit set to one in the CDB control byte has completed. Service Delivery or Target Failure : T h e command has been ended due to a service delivery failure or targe t device malfunction. All output parameters may be invalid. The actual protocol events corresponding to a response of Task Complete , Linked Command Complete , L i n ked Command Complete \(with flag\ or Service Delivery or Target Failure shall b e specified in each protocol standard. A n a p p l i c a t i o n c l i e nt requests execution of a linked command by setting the link bit to one in the CDB control byte a s s p ecified in 5.1.2. The task attribute is determined by the Task Attribute argument specified for the firs t c o m m a n d i n the sequence. Upon receiving a response of Linked Command Complete or Linked Command C o m p l e t e \( w i th flag\ , an application client may issue the next command in the series through a n E x e c u t e C o m m a n d r emote procedure call having the same task identifier. The Task Attribute argument shall be o m i t t e d . I f t h e a p p l i c a t i o n c l i e n t i ssues the next command without waiting for one of the linked command complete responses, the overlapped command condition described in 5.6.2 may result. 5.1 Command Descriptor Block T h e c o m m a n d d e s c r i p t o r b l o c k d e f i n e s the operation to be performed by the device server. For some commands, t h e c o m m a n d d e s c r i p t o r b l o c k i s accompanied by a list of command parameters contained in the Data-Out buffer d e f i n e d i n c l a u s e 5 . T h e p a r a m e t e r s r e q u ired for each command are specified in the applicable SCSI-3 command standards. Validation of reserved fields in a CDB is a logical unit option. If a logical unit validates reserved CDB fields an d r e c e i v e s a r e s e r v e d f i e l d w i t h i n t h e C D B t h a t i s n o t z e r o o r r e c e i v e s a r e s e r ved CDB code value, the logical unit shall t e r m i n a t e t h e command with CHECK CONDITION status; the sense key shall be set to ILLEGAL REQUEST with a n additional sense code of INVALID FIELD IN CDB \(see the SPC standard\ It shall also be acceptable for a logical unit to interpret a field or code value in accordance with a future revision to an SCSI-3 standard. F o r a l l c o m m a n d s , i f t h e l o g i c a l u n i t d e t e c t s a n i n v a lid parameter in the command descriptor block, then the logical unit shall complete the command without altering the medium. A s s h o w n i n t a b l e 1 , a l l c o m m a n d d e s c r i p t o r b l o c k s s h a l l h a v e a n o p eration code as the first byte and a control byte a s t he last byte. The remaining parameters depend on the command to be executed. All SCSI protoco l atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 43 Bit Byte 7 6 5 4 3 2 1 0 0 Operation Code 1 Command-Specific Parameters n -1 n Control Table 1 -- Format of Command Descriptor Block Bit 7 6 5 4 3 2 1 0 Group Code Command Code Table 2 -- Operation Code Bit 7 6 5 4 3 2 1 0 Vendor Specific Reserved NACA Flag Link Table 3 -- Control Field specifications shall accept command descriptor blocks less than or equal to 16 bytes in length. Comman d descriptor blocks shall not exceed sixteen bytes in length. 5.1.1 Operation Code The first byte of an SCSI command descriptor block shall contain an operation code. The operation code \(table 2 \ o f t h e c o m m a n d d e scriptor block has a group code field and a command code field. The three-bit group code f i e l d p r o v i d e s for eight groups of command codes. The five-bit command code field provides for thirty-tw o c o m m a n d c o d e s i n e a c h g r o u p . A t o t a l o f 2 56 possible operation codes exist. Operation codes are defined in the SCSI command standards. The group code for CDBs specified therein shall correspond to the length of th e command descriptor as set forth in the following list. The group code specifies one of the following groups: Group 0 - six-byte commands Group 1 - ten-byte commands Group 2 - ten-byte commands Group 3 - reserved Group 4 - sixteen-byte commands Group 5 - twelve-byte commands Group 6 - vendor specific Group 7 - vendor specific 5.1.2 Control Field The control field is the last byte of every command descriptor block. The control field is defined in table 3. atend X3T10/994D revision 18 August 10, 1995 44 working draft SCSI-3 Architecture Model A l l S C S I - 3 p r o t o c o l s p e c i f i c a t i o n s a nd protocol implementations shall provide the functionality needed for a logical unit to implement the NACA bit, link bit and flag bit as described herein. T h e N A C A \(Normal ACA\ Subclause 5.6.1.1 specifies the actions to be taken by a logical unit in response to an auto contingent allegiance condition for NACA bit values of one or zero. All logical units shall implement support for the Normal ACA value o f zero and may support the Normal ACA value of one. The ability to support a Normal ACA value of one i s indicated in standard INQUIRY data. I f t h e N A C A bit is set to a value which is not supported, the logical unit shall complete the command with a status o f C H E C K C O NDITION and a sense key of ILLEGAL REQUEST. The rules for handling the resulting aut o contingent allegiance condition shall be in accordance with the supported bit value. T h e l i n k b i t i s u s ed to continue the task across multiple commands. The flag bit may be used, in conjunction with the link bit, to notify the initiator in an expedited manner that the command has completed. S u p p o r t f o r t h e l i n k b i t i s a l o g i c a l u n i t o p tion. A link bit of one indicates that the initiator requests continuation of the t a s k a c r o s s t w o o r m o r e S C S I c o m m a n d s . I f t h e l i n k b i t i s o n e a n d t h e f l a g b it is zero and if the command completes s u c c e s s f u l l y , a l ogical unit that supports the link bit shall continue the task and return a status of INTERMEDIATE or INTERMEDIATE-CONDITION MET and a service response of Linked Command Complete \(see 5.2.\ S u p p o r t for the flag bit is a logical unit option. If the link bit and flag bit are both set to one and if the comman d c o m p l e t e s w i t h a status of INTERMEDIATE or INTERMEDIATE-CONDITION MET a logical unit that supports the flag bit shall return a service response of Linked Command Complete \(with flag\ . T h e logical unit shall complete the command with a status of CHECK CONDITION and a sense key of ILLEGAL REQUEST if: e\ The link bit is set to one and the logical unit does not support linked commands or, f\ The flag bit is set to one and the logical unit does not support the flag bit or, g\ The flag bit is set to one and the link bit is set to zero. 5.2 Status T h e s t a t u s c o des are specified in table 4. Status shall be sent from the logical unit to the application clien t w h e never a command ends with a service response of Task Complete , Linked Command Complete , o r L i n k e d C o m mand Complete \(with flag\ . The receipt of any status, except INTERMEDIATE o r INTERMEDIATE-CONDITION MET, shall indicate that the associated task has ended. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 45 Status byte codes Status 0h 2h 4h 8h 10h 14h 18h 22h 28h 30h All other codes GOOD CHECK CONDITION CONDITION MET BUSY INTERMEDIATE INTERMEDIATE-CONDITION MET RESERVATION CONFLICT COMMAND TERMINATED TASK SET FULL ACA ACTIVE Reserved Table 4 -- Status Codes Definitions for each status byte code are given below. GOOD. This status indicates that the Device Server has successfully completed the task. C H E C K C O N D I T I O N . T h i s s t a t u s indicates that an auto contingent allegiance condition has occurred \(see 5.6.1\ C O N D I T I O N M E T . T h i s status is returned whenever the requested operation specified by an unlinked command is satisfied \(see the SEARCH DATA \( SBC\ SBC\ B U S Y . T h i s s tatus indicates that the logical unit is busy. This status shall be returned whenever a logical unit is unable to accept a command from an otherwise acceptable initiator \(i.e., no reservation conflicts\ Th e recommended initiator recovery action is to issue the command again at a later time. INTERMEDIATE. This status or INTERMEDIATE-CONDITION MET shall be returned for each successfull y c o m p l e t e d c o m m and in a series of linked commands \(except the last command\ unless the command i s t e r m i n a t ed with CHECK CONDITION, RESERVATION CONFLICT, TASK SET FULL, BUSY o r C O M M A N D T E R M I N A T E D s t a t u s . I f I N T E R M E D I A T E o r I N T E R M E D I A T E - CONDITION MET status is not returned, the series of linked commands is terminated and the task is ended. I N T E R M EDIATE-CONDITION MET. This status is returned whenever the operation requested by a linke d c o m m a n d i s s a t i s f i e d \( s e e t h e SEARCH DATA \(SBC\ SBC\ i s t e rminated with CHECK CONDITION, RESERVATION CONFLICT, TASK SET FULL, BUSY o r C O M M A N D T E R M I N A T E D s t a t u s . I f I N T E R M E D I A T E o r I N T ERMEDIATE-CONDITION MET status is not returned, the series of linked commands is terminated and the task is ended. R E S E R V A T I O N CONFLICT. This status shall be returned whenever an initiator attempts to access a logical unit o r a n e x t e n t w i t h i n a l o g i c a l u n i t t h a t i s reserved with a conflicting reservation type for another SCSI device \(see the Reserve commands in the SPC standard\ again at a later time. C O M M A N D T E R M I N A T E D . T h i s s t a t u s shall be returned whenever the logical unit terminates a task in response t o a T E R M I N A T E T A S K t a s k m a nagement request \(see 6.6\ allegiance has occurred \(see 5.6.1\ T A S K S E T F U L L . This status shall be implemented if the logical unit supports the creation of tagged tasks \(see object definition 7\ This status shall be returned when the logical unit receives a command and does not have enough resources to enter the associated task in the task set. atend X3T10/994D revision 18 August 10, 1995 46 working draft SCSI-3 Architecture Model A C A A C T I V E . T h is status shall be returned when an auto contingent allegiance exists within a task set and a n initiator issues a command for that task set when at least one of the following is true: a\ There is a task with the ACA attribute in the task set; b\ The initiator issuing the command did not cause the ACA condition; c\ T h e t a s k c r e a t e d to execute the command did not have the ACA attribute and the NACA bit was set to one in the CDB control byte of the faulting command \(see 5.6.1\ The initiator may reissue the command after the ACA condition has been cleared. I f more than one condition applies to a completed task, the report of a BUSY, RESERVATION CONFLICT , ACA ACTIVE or TASK SET FULL status shall take precedence over the return of any other status for that task. 5.3 Protocol Services in Support of Execute Command T h i s section describes the protocol services which support the Execute Command remote procedure call. Al l S C S I - 3 p r otocol specifications shall define the protocol-specific requirements for implementing the Send SCS I C o m m a n d P r o t o c o l s e r v i c e r e q u e s t a n d t h e C o m m a n d C o m p l e t e R e c e i ved confirmation described below. Support f o r t he SCSI Command Received indication and Send Command Complete response by an SCSI-3 protoco l s t a n d a r d i s o p t i o n a l . All SCSI-3 I/O systems shall implement these protocols as defined in the applicable protocol specification. U n l e s s s t a t e d o t h e r w i s e , a r g u m e n t d e f i n i tions and the circumstances under which a conditional argument must be present are the same as in clause 5. Protocol Service Request: Send SCSI Command \(Task Address, CDB, [Task Attribute], [Data-Out Buffer ], [Command Byte Count], [Autosense Request] ||\ Protocol Service Indication: SCSI Command Received \(Task Identifier, [Task Attribute], CDB, [Autosense Request] ||\ | Autosense Request : T h i s parameter is only present if the Autosense Request parameter wa s s p e c i f i e d in the Send SCSI Command call and autosense delivery i s supported by the SCSI-3 protocol and logical unit. Protocol Service Response \(from device server\ Send Command Complete \(Task Identifier, [Sense Data ], Status, Service Response ||\ T h e S e n s e D a t a a r gument, if present, instructs the target's service delivery port to return sense information to the initiator automatically \(see 5.6.4.2\ Protocol Service Confirmation: Command Complete Received \(Task Address, [Data-In Buffer], [Sense Data], Status, Service Response ||\ atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE Device Server Data Buf fer Application Client Data Buf fer Application Client Buf fer Of fset Command Byte Count Byte Count Requested by Device Server August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 47 Figure 19 : Model for buffered data transfers 5.3.1 Data Transfer Protocol Services T h e d a t a t r a n s f e r s e r v i c e s d e s c r i b e d i n t h i s s e c t i o n a r e p r ovided to complete the functional model of target protocol s e r v i c e s w h ich support the Execute Command remote procedure call. All SCSI-3 protocol standards shall define the protocols required to implement these services. I t i s a s s u m e d t h a t t h e b u f f e r i n g r e s o u r c e s a v a i lable to the device server are limited and may be much less than the a m o u n t o f d a t a t h a t c a n b e t r a n s f e r r e d i n o n e S C S I c ommand. In this case, such data must be moved between the a p p l i c a t i o n c l i e n t a n d t h e m e d i a i n s e g m e n t s t h a t a r e s m a l l e r t h a n the transfer size specified in the SCSI command. T h e a m o u n t o f d a t a m o v e d p e r r e q u e s t is usually a function of the buffering resources available to the logical unit. Figure 19 shows the model for such incremental data transfers. A s s h o w n i n f i g u r e 1 9 , t h e a p p l i c a t i o n c l i e n t ' s b u f f e r is a single, logically contiguous block of memory large enough t o h o l d a l l t h e d a t a r e q u i r e d b y t h e c o m m a n d . T h e m o d e l r e q u i r e s u n i d i r ectional data transfer. That is, the execution of an SCSI-3 command shall not require the transfer of data for that command both to and from the application client. T h e m o v e m e n t o f d a t a b e t w een the application client and device server is controlled by the following parameters: Application client buffer O f f s e t i n b y t e s f r o m t h e beginning of the application client's buffer to the first offset: byte of transferred data. Byte count requested by Number of bytes to be moved by the data transfer request. device server: Command byte count: U p p e r l i m i t o n t h e e x t e n t o f t h e d a t a t o b e transferred by the SCSI command. I f a n S C S I - 3 p r o t o c o l s u p p o r t s r a n d o m b u f f e r a c c e s s, as described below, the offset and byte count specified for each data s e g m e nt to be transferred may overlap. In this case the total number of bytes moved for a command is not a reliabl e indicator of transfer extent and shall not be used by an initiator or target implementation to determine the command byte count. A l l S C S I - 3 p r otocol specifications and initiator implementations shall support a resolution of one byte for the abov e parameters. A target device may support any convenient resolution. atend X3T10/994D revision 18 August 10, 1995 48 working draft SCSI-3 Architecture Model R a n d o m b u f f e r a c c e s s o c c u r s w h e n t h e d e v i c e s e r v e r r e q u e s t s d a t a t r ansfers to or from segments of the application client's b u f f e r w h i c h h a v e a n a rbitrary offset and extent. Buffer access is sequential when successive transfers access a series of m o n o t o n i c a l l y i n c r e a s i n g , a d j o i n i n g b u f f e r s e g m e n t s . Support for random buffer access by an SCSI-3 protocol specification i s o p t i o n a l . A d e v i c e s e r v e r i m p l e m e n t a t i o n d e s i g n e d for any protocol implementation should be prepared to use sequential buffer access when necessary. The following clauses specify the LLP confirmed services used by the device server to request the transfer of command data to or from the application client. The initiator protocol service interactions are unspecified. 5.3.2 Data-In Delivery Service Request: Send Data-In \(Task Identifier, Device Server Buffer , Application Client Buffer Offset, Request Byte Count||\ Argument Descriptions: Task Identifier: See object definition 7. Device server buffer : Buffer from which data is to be transferred. Application client buffer O f f s e t i n b y t e s f r o m t h e s t a r t o f t h e b u f f e r t o t he location within the application offset: client\222s buffer to receive the first byte of data. | Request byte count: Number of bytes to be moved by this request. Confirmation: Data Delivered \(Task Identifier ||\ T h i s c o n f i r m a t i o n n o t i f i e s t h e d e v i c e s e r v e r t h a t t h e s p ecified data was successfully delivered to the application client buffer. 5.3.3 Data-Out Delivery service Request: Receive Data-Out \(Task Identifier, Application Client Buffer Offset, Request Byte Count, Device Server Buffer ||\ Argument Descriptions: See 5.3.2. Confirmation: Data-Out Received \(Task Identifier||\ This confirmation notifies the device server that the requested data has been successfully delivered to its buffer. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 49 5.4 Task and Command Lifetimes T h i s c l a u s e s p e c i f i e s t h e e v e n t s d e l i m i t i n g t h e b e g inning and end of a task or pending SCSI-3 command from the viewpoint of the device server and application client. T h e d e v i c e s erver shall create a task upon receiving an SCSI Command Received indication unless the comman d represents a continuation of a linked command as described in clause 5. The task shall exist until: a\ The device server sends a protocol service response for the task of Task Complete . b\ A power on condition occurs. c\ The target executes a hard reset operation as described in 5.6.6. d\ The task manager executes an ABORT TASK referencing the specified task e\ T h e t a s k m a n a g e r e x e c u t e s a n A B O R T T A S K S E T or CLEAR TASK SET task management function directed to the task set containing the specified task. A n S C S I - 3 c o m m a n d i s p e nding when the associated SCSI Command Received indication is passed to the device server. T h e c o m m a n d e n d s o n t h e o c c u r r e n c e o f o n e o f t h e c onditions described above or when the device server sends a service response for the task of Linked Command Complete or Linked Command Complete \(with flag\ . The application client assumes that the task exists from the time the Send SCSI Command protocol service request i s invoked until it receives one of the following target responses: a\ A service response of Task Complete for that task, b\ A unit attention condition with one of the following additional sense codes: COMMANDS CLEARED BY ANOTHER INITIATOR \(if in reference to the task set containing the task\ POWER ON, RESET, TARGET RESET. c\ A service response of Service Delivery or Target Failure for the command, I n t h i s c a s e , s ystem implementations shall guarantee that the task associated with the failed command has ended. d\ A s e r v i c e r e s p o n s e o f F u n c t i o n C o m p l e t e f o llowing an ABORT TASK task management request directed to the specified task e\ A s e r v i c e response of Function Complete following an ABORT TASK SET or CLEAR TASK SET tas k management function directed to the task set containing the specified task. f\ A service response of Function Complete in response to a TARGET RESET. T h e a p p l i c a t i o n c l ient assumes the command is pending from the time it calls the Send SCSI Command protocol service u n t i l o n e o f t h e a b o v e r e s p o n s e s o r a s e r v i c e r e s p o n s e o f L i n k e d C o m m a n d C o m p l e t e o r Linked Command Complete \(with flag\ is received. As discussed in 4.6.1, when an SCSI-3 protocol does not require state synchronization, there will usually be a time skew b e t w e e n t h e c o m p l e t i o n o f a d e v i c e s e r v e r r e q u e s t - r e s p o n s e t r a n s a c tion as seen by the application client and device server. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ime T ime T ime T ime Application Client Application Client T ask T ask W aiting W aiting W orking W orking Activity Activity Activity Activity Initiator Initiator T arget T arget 1 1 2 2 3 3 4 4 X3T10/994D revision 18 August 10, 1995 50 working draft SCSI-3 Architecture Model Figure 20 : Command processing events A s a r e s u l t , t h e l i f e t i m e o f a t a s k o r c o m m a n d a s it appears to the application client will usually be different from the lifetime observed by the device server. 5.5 Command Processing Examples The following clauses give examples of the interactions for linked and unlinked commands. 5.5.1 Unlinked Command Example A n u n l i n k e d c o m m a n d i s used to show the events associated with the processing of a single device service request. This example does not include error or exception conditions. The numbers in figure 20 identify the events described below. 1. T h e a p p l i c a t i o n c l i e n t p e r f o r m s a n E x e c u t e C o m m a n d r e m o t e p r o c e d u r e c a l l b y invoking the Send SCSI Command protocol service to send the CDB and other input parameters to the logical unit. 2. T h e Device Server is notified through an SCSI Command Received indication containing the CDB and command parameters. A task is created and entered into the task set. The device server may invoke the appropriate dat a delivery service one or more times to complete command execution. 3. T h e task ends upon completion of the command. On command completion, the Send Command Complet e p r o t o c o l s e r v i c e is invoked to return a status of GOOD and a service response of Command Complete Tas k Complete . 4. A confirmation of Command Complete Received is sent to the ULP by the initiator's service delivery subsystem. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ime T ime T ime T ime Application Client Application Client Application Client Application Client T ask A T ask A W aiting W aiting W aiting W aiting W orking W orking W aiting W aiting W orking W orking Activity Activity Activity Activity Initiator Initiator Device Server Device Server 1 1 8 8 4 4 5 5 2 2 3 3 6 6 7 7 August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 51 Figure 21 : Linked Command Processing Events 5.5.2 Linked Command Example A t a s k m a y c o n s i s t o f m u l t i p l e c o m m a n d s " l i n k e d " t o g e t h e r . After the logical unit notifies the application client that a linked command has successfully completed, the application client issues the next command in the series. The following example shows the events in a sequence of two linked commands. The numbers in figure 21 Identify the events described below. 1. T h e a p p l i c a t i o n c l i e n t p e r f o r m s a n E x e c u t e C o m m a n d r e m o t e p r o c e d u r e c a l l b y invoking the Send SCSI Command p r o t o c o l s e r v i c e t o s e n d the CDB and other input parameters to the logical unit. The link bit is set to one in the CDB control byte \(see 5.1.2\ 2. The target's service delivery port issues an SCSI Command Received indication to the device server. The device server creates a task \(task A\ 3. U p o n c o m p l e t i o n o f t h e f i r s t command, the device server invokes the Send Command Complete protocol service w i t h t h e S t a t u s a r g u m e n t s et to INTERMEDIATE or INTERMEDIATE-CONDITION MET and a Service Response of Linked Command Complete . Task A is not terminated. 4. T h e i nitiator's service delivery port returns the status and service response to the ULP by means of a Comman d Complete Received confirmation. 5. T h e A pplication Client performs an Execute Command remote procedure call by means of the Send SCS I C o m m a n d protocol service as described in step 1. The Task Attribute argument is omitted. The link bit in the CDB control byte is clear. 6. The device server receives the last command in the sequence and executes the operation. 7. The command completes successfully. Task A is terminated. A protocol service response of Task Complete , with status GOOD, is sent to the application client. atend X3T10/994D revision 18 August 10, 1995 52 working draft SCSI-3 Architecture Model 8. T h e L L P d e l i v e r s a C o m m a n d C o m p l e t e R e c e i v e d c onfirmation to the application client, which contains the service response and status. 5.6 Command Processing Considerations and Exception Conditions T h e f o l l o w i n g clauses describe some exception conditions and errors associated with command processing and th e sequencing of commands. 5.6.1 Auto Contingent Allegiance T h e a uto contingent allegiance condition shall exist within the task set when the logical unit completes a command b y returning a COMMAND TERMINATED or CHECK CONDITION status \(see 5.2\ I n t h e f o l l o w i n g d i s c u s s i o n , t h e t e r m " f a u l t i n g c o m m a n d " r e f e r s to the command that completed with a CHECK CONDITION o r C O M M AND TERMINATED status. The term "faulted initiator" refers to the initiator receiving th e C O M M A N D T E R M I N A T E D o r C H E C K C O N D I T I O N s t a t u s . T h e t e r m " faulted task set" refers to the task set having the auto contingent allegiance condition. 5.6.1.1 Logical Unit Response to Auto Contingent Allegiance The auto contingent allegiance condition shall not cross task set boundaries and shall be preserved until it is cleared as d e s c r i b e d i n 5.6.1.2. If requested by the application client and supported by the protocol and logical unit, sense data shall be returned as described in 5.6.4.2. Notes: 1. T h e S C S I - 2 contingent allegiance condition and extended auto contingent allegiance condition have been replaced in SCSI-3 by auto contingent allegiance. 2. I f t h e S C S I - 3 p r o t o c o l d o e s n o t e n f o r c e s t ate synchronization as described in 4.6.1, there may be a time delay between the occurrence of the auto contingent allegiance condition and the point at which the initiator becomes aware of the condition. A f t e r s ending status and a service response of Task Complete , the logical unit shall modify the state of all tasks in the faulted task set as described in clause 7. A t a s k created by the faulted initiator while the auto contingent allegiance condition is in effect may be entered into th e f a u l t e d t a s k s e t u n d e r the conditions described below. Tasks created by other initiators while the ACA condition is in effect shall not be entered into the faulted task set and shall be completed with a status of ACA ACTIVE. As described in 5.6.1.2, the setting of the NACA bit in the control byte of the faulting command determines the rules that a p p l y t o a n A C A c o n d i t i o n c a u s e d b y t h a t c o m m a n d . If the NACA bit was set to zero the SCSI-2 contingent allegiance rules s h a l l apply. In that case, the completion of a subsequent command from the faulted initiator with a status of CHEC K CONDITION or COMMAND TERMINATED shall cause a new auto contingent allegiance condition to exist. The rules for r e s p o n d i n g to the new auto contingent allegiance condition shall be determined by the state of the NACA bit in the ne w faulted command. If the NACA bit was set to one in the CDB control byte of the faulting command, then a new task created while the AC A condition is in effect shall be entered into the faulted task set provided: a\ The command was originated by the faulted initiator, b\ The task has the ACA attribute, c\ No other task having the ACA attribute is in the task set. T h e a u t o c o n t i n g e n t a l l e g i a nce condition shall not be cleared. If the conditions listed above are not met, the newly created task shall not be entered into the task set and shall be completed with a status of ACA ACTIVE. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 53 I f a t a s k h a v i n g t h e A C A a t t r i b u t e i s r e c e ived and no auto contingent allegiance condition is in effect for the task set or if the N A C A b i t w a s set to zero in the CDB for the faulting command, then the ACA task shall be completed with a status o f C H E C K C ONDITION. The sense key shall be set to ILLEGAL REQUEST with an additional sense code of INVALI D MESSAGE ERROR. As noted in 5.6.1.2, a new auto contingent allegiance condition shall be established. 5.6.1.2 Clearing an Auto Contingent Allegiance Condition An auto contingent allegiance condition shall always be cleared after a power on condition or a hard reset \(see 5.6.6\ I f t h e l o g i c a l u nit accepts a value of one for the NACA bit and this bit was set to one in the CDB control byte of the faulting c o m m a n d , t h e n t h e a u t o c o n t i n g e n t a l l e g i a n c e c o n d i t i o n m a y a l s o b e c l e a r e d b y means of a CLEAR ACA task management function issued by the faulting initiator as described in 6.3. I f t h e N A C A b i t i s s e t t o z e r o i n t h e C D B c o n t r o l byte of the faulting command, then the SCSI-2 rules for clearing contingent a l l e g i a n c e s h a l l a p p l y . I n t h i s case, the logical unit shall also clear the associated contingent allegiance condition upon the return of sense data by means of the autosense mechanism described in 5.6.4.2. W h i l e t he SCSI-2 rules for clearing the ACA condition are in effect, a logical unit that supports the CLEAR ACA tas k m a n a g e m e n t f u n c t i o n s h a l l i g n o r e a l l C L E A R ACA requests and shall return a service response of Function Complete \(see 6.3\ T h e s t a t e o f a l l t a s k s i n t h e t a s k s e t w h e n an auto contingent allegiance condition is cleared shall be modified as described in clause 7. 5.6.2 Overlapped Commands An overlapped command occurs when an application client reuses a task address in a new command while a previou s c o m m a n d t o w h i c h t h a t a d d r e s s w a s a s s i g n e d i s s t i l l p e nding as specified in 5.4. \(The format of a task address is described in object definition 7.\ Each SCSI-3 protocol standard shall specify whether or not a logical unit is required to detect overlapped commands. A l o g i c a l u n i t t h a t d e t e c t s a n o v e r l a p p e d c o m m a n d s h a l l a b o r t a l l tasks for the initiator in the task set and shall return CHECK C O N D I T I O N s t a t u s f o r t h a t c o m m a nd. If the overlapped command condition was caused by an untagged task or a tagged task with a tag value exceeding FFh, then the sense key shall be set to ABORTED COMMAND and the additional sense c o d e s h a l l be set to OVERLAPPED COMMANDS ATTEMPTED. Otherwise, an additional sense code of TAGGE D O V E R L A P P E D T A S K S s h a l l be returned with the additional sense code qualifier byte set to the value of the duplicate tag. IMPLEMENTORS NOTES: 1\ A n o v e r l a p p e d c o m m a n d m a y b e i n d i c a t i v e o f a s e r i o u s e r r o r a n d , i f n o t d e t e c ted, could result in corrupted data. This is considered a catastrophic failure o n t h e p a r t o f t h e i n itiator. Therefore, vendor-specific error recovery procedures may be required to guarantee the data integrity on the medium. The target logical unit 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 logical units may not detect an overlapped command until after the command descriptor block has been received. 5.6.3 Incorrect Logical Unit Selection The target's response to an incorrect logical unit identifier is described in the following paragraphs. The logical unit identifier may be incorrect because: a\ The target does not support the logical unit \(e.g., some targets support only one peripheral device\ atend X3T10/994D revision 18 August 10, 1995 54 working draft SCSI-3 Architecture Model I n r e s p o n s e t o a n y o t h e r c o m m a n d e x c e p t R E Q U E S T S E N S E a n d I N Q U I R Y , the target shall terminate the command w i t h C H E C K C O N D I T I O N s t a t u s . S e n s e d a t a s h a l l b e s e t t o t h e v a l u e s s p e c i f i e d for the REQUEST SENSE command above; b\ The target supports the logical unit, but the peripheral device is not currently attached to the target. I n r e s p o n s e t o a n I N Q U I R Y c o m m a n d t h e t a r g e t s h a l l return the INQUIRY data with the peripheral qualifier set to the v a lue required in the SPC standard. In response to a REQUEST SENSE command, the target shall return sens e d a t a . T h e s e n s e k e y s h a l l b e s e t t o I L L E G A L R E Q U E S T a n d t h e a d d i t i o n a l s e n s e code shall be set to LOGICAL UNIT NOT SUPPORTED. I n r e s p o n s e t o a n y o t h e r c o m m a n d e x c e p t R E Q U E S T S E N S E a n d I N Q U I R Y , the target shall terminate the command w i t h C H E C K C O N D I T I O N s t a t u s . S e n s e d a t a s h a l l b e s e t t o t h e v a l u e s s p e c i f i e d for the REQUEST SENSE command above; c\ The target supports the logical unit and the peripheral device is attached, but not operational. I n r e s p o n s e t o a n I N Q U I R Y c o m m a n d t h e t a r g e t s h a l l return the INQUIRY data with the peripheral qualifier set to the value required in the SPC standard. In response to REQUEST SENSE, the target shall return sense data. The target's response to any command other than INQUIRY and REQUEST SENSE is vendor specific; d\ T h e t a r g e t s u p p o r ts the logical unit but is incapable of determining if the peripheral device is attached or is no t operational when it is not ready. I n r e s p o n s e t o a n I N Q U I R Y c o m m a n d t h e t a r g e t s h a l l return the INQUIRY data with the peripheral qualifier set to the v a l u e s pecified in the SPC standard. In response to a REQUEST SENSE command the target shall return th e REQUEST SENSE data with a sense key of NO SENSE unless an auto contingent allegiance exists. The target's response to any other command is vendor specific. 5.6.4 Sense Data S e n s e d a t a s h a l l be made available by the logical unit in the event a command completes with a CHECK CONDITIO N s t a t u s , C O M MAND TERMINATED status or other conditions. The format, content and conditions under which sense data s h a l l be prepared by the logical unit are specified in this standard, the SPC standard, the applicable device comman d standard and applicable SCSI-3 protocol standard. Sense data shall be preserved by the logical unit for the initiator until it is transferred by one of the methods listed below or until another task from that initiator is entered into the task set. This information may be obtained by the initiator through: a\ The REQUEST SENSE command specified in the SPC standard; b\ An asynchronous event report; c\ Autosense delivery. The following clauses describe the last two delivery methods. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 55 5.6.4.1 Asynchronous Event Reporting A s y n c h r o n o u s event reporting is used by a logical unit to signal another device that an asynchronous event has occurred. T h e m e c h a n i s m a u t o m a t i c a l l y r e t u r n s s e n s e d a t a associated with the event. Each SCSI protocol specification shall provide a m e c h a n i s m f o r a s y n c h r onous event reporting, including a procedure whereby an SCSI device can selectively enable or d i s a b l e a s y n c h r o n o u s e v e n t r e p o r t s f r o m b e i n g s e n t t o i t b y a specific target. \(In this subclause, references to asynchronous e v e n t r e p o r t i n g a s s u m e t h a t t h e d e v i c e t o b e notified has enabled asynchronous event reports from the target.\ asynchronous event reporting is a logical unit option. I M P L E M E N T O R S N O T E : A n S CSI device which can produce asynchronous event reports at initialization time should provide means to defeat these r e p o r t s. This can be done with a switch or jumper wire. Devices which implement saved parameters may alternatively save the asynchronous event reporting permissions either on a per SCSI device basis or as a system wide option. P a r a m e t ers affecting the use of asynchronous event reporting are contained in the control mode page \(see the SP C standard\ Asynchronous event reporting is used to signal a device that one of the four events listed below has occurred: a\ an error condition was encountered after command completion; b\ a newly initialized device is available; c\ some other type of unit attention condition has occurred; d\ an asynchronous event has occurred. 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 report to inform the initiator of the failure. A n e x a m p l e o f t h e s e c o n d case above is a logical unit that generates an asynchronous event report, following a power-on cycle, to notify other SCSI devices that it is ready to accept I/O commands. A n e x a m p l e o f t h e t h i r d c a s e a b o v e i s a d e v i c e t h a t s u p p o r t s r e m o v a b l e m e d i a. Asynchronous event reporting may be used t o i nform an initiator of a not-ready-to-ready transition \(medium changed\ e.g., activating a write protect switch or activating a start or stop switch\ A n e xample of the fourth case above is a sequential-access device performing a REWIND command with the immediate bit set to one. An asynchronous event report may be used to inform an initiator that the beginning of medium has been r e a c h e d . C o m p l e t i o n o f a C D - R O M A U D I O P L A Y c o m m a n d s t a r t e d i n t h e i m m e d i a t e mode is another example of this case. Sense data accompanying the report identifies the condition \(see 5.6.4\ A n e r r o r c o n d i t i o n o r u n i t a t t e n t i o n c o n d i t i o n s h a l l b e r e p o r t e d to a specific initiator once per occurrence of the event causing it. The logical unit may choose to use an asynchronous event report or to return CHECK CONDITION status on a s u b s e q u e n t c o m m a n d , b u t n o t b oth. Notification of command-related error conditions shall be sent only to the device that initiated the affected task. A s y n c h r o n o u s e v e n t r e p o r t s m a y b e u s e d to notify devices that a system resource has become available. If a logical unit uses this method of reporting, the sense key in the AER sense data shall be set to UNIT ATTENTION. atend X3T10/994D revision 18 August 10, 1995 56 working draft SCSI-3 Architecture Model 5.6.4.2 Autosense A u t o s e n s e is the automatic return of sense data to the application client coincident with the completion of an SCSI- 3 c o m m a n d u n d e r t h e c o n d i t i o n s d e scribed below. The return of sense data in this way is equivalent to an explicit command f r o m the application client requesting sense data immediately after being notified that an ACA condition has occurred . Inclusion of autosense support in an SCSI-3 protocol standard is optional. A s s p e c i f i e d i n clause 5, the application client may request autosense service for any SCSI command. If supported by the p r o t o c o l a n d l o g i c a l u n i t a n d r e q u e s t e d b y t h e a p p l i c a t i o n c l i e n t , t h e d e v i c e s erver shall only return sense data in this manner c o i n c i d e n t w i t h the completion of a command with a status of CHECK CONDITION or COMMAND TERMINATED. Th e sense data shall then be cleared. Protocol standards that support autosense shall require an autosense implementation to: a\ Notify the logical unit when autosense data has been requested for a command and b\ Inform the application client when autosense data has been returned upon command completion \(see 5\ I t i s n o t a n e r r o r f o r t h e a p p l i c a t i o n c l ient to request the automatic return of sense data when autosense is not supported by t h e S C S I - 3 protocol or logical unit implementation. If the application client requested the return of sense data through the a u t o s e n s e f a c i l i t y a n d t h e p r o t o c o l s e r v i c e l a y e r d o e s n o t s u p p o r t t h i s feature, then the confirmation returned by the initiator's s e r v i c e d e livery port should indicate that no sense data was returned. If the protocol service layer supports autosense but t h e l o g i c a l u n i t d o e s n o t , t h e n the target should indicate that no sense data was returned. In either case, sense information shall be preserved and the application client may issue a command to retrieve it. 5.6.5 Unit Attention Condition E a c h l o g i c a l u n i t s h a l l g e n e r a t e a unit attention condition whenever the logical unit has been reset as described in 5.6.6 or b y a p o w e r - o n r e s e t . I n a d d i t i o n , a l o g i c a l u n i t shall generate a unit attention condition for each initiator whenever one of the following events occurs: a\ A removable medium may have been changed; b\ The mode parameters in effect for this initiator have been changed by another initiator; c\ The version or level of microcode has been changed; d\ Tasks for this initiator were cleared by another initiator; e\ INQUIRY data has been changed; f\ The mode parameters in effect for the initiator have been restored from non-volatile memory; g\ A change in the condition of a synchronized spindle; h\ Any other event requiring the attention of the initiator. Logical units may queue unit attention conditions. After the first unit attention condition is cleared, another unit attentio n condition may exist \(e.g., a power on condition followed by a microcode change condition\ A u n i t a t t e n t i o n c o n d i t i o n s h a l l p e r s i s t on the logical unit for each initiator until that initiator clears the condition as described in the following paragraphs. I f a n I N Q U I R Y c o m m a nd is received from an initiator to a logical unit with a pending unit attention condition \(before th e l o g i c a l u n i t g e n e r a t e s t h e a u to contingent allegiance condition\ shall not clear the unit attention condition. I f a request for sense data is received from an initiator with a pending unit attention condition \(before the logical uni t establishes the automatic contingent allegiance condition\ a\ report any pending sense data and preserve the unit attention condition on the logical unit, or, b\ report the unit attention condition. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 57 I f t h e s e c ond option is chosen \(reporting the unit attention condition\ and may clear the unit attention condition for that initiator. | I f t h e l o g i c a l u n i t h a s a l r e a d y g e n erated the auto contingent allegiance condition for the unit attention condition, the logical unit 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 auto contingent allegiance condition for the unit attention condition\ n o t p e r f o rm the command and shall report CHECK CONDITION status unless a higher priority status as defined by th e logical unit is also pending \(see 44\ I f a l o g i c a l u n i t s u c c e ssfully sends an asynchronous event report informing the initiator of the unit attention condition, then the logical unit shall clear the unit attention condition for that initiator on the logical unit \(see 5.6.4.1\ 5.6.6 Hard Reset H a r d r e set is a target response to a TARGET RESET task management request, \(see 6.5\ or a reset event within th e s e r v i c e d elivery subsystem. The definition of reset events is protocol and interconnect specific. Each SCSI-3 protoco l s t a n dard shall specify the target response to a reset event including the conditions under which a hard reset shall b e executed. To execute a hard reset a target shall: a\ Abort all tasks in all task sets; b\ Clear all auto contingent allegiance conditions; c\ Release all SCSI device reservations; d\ Return any device operating modes to their appropriate initial conditions, similar to those conditions that would be f o u n d f o l l o w i n g device power-on. The MODE SELECT conditions \(see the SPC standard\ l a s t s a v e d v a l u e s i f s a v e d v a l u e s h a v e b e e n established. MODE SELECT conditions for which no saved values have been established shall be returned to their default values; e\ Unit Attention condition shall be set \(see 5.6.5\ I n a d d i t i o n t o t h e a b o v e , t h e t a r g e t s h a l l e x e c u t e any additional functions required by the applicable protocol or interconnect specifications. atend taskfunc.wp X3T10/994D revision 18 August 10, 1995 58 working draft SCSI-3 Architecture Model 6 Task Management Functions T a s k management functions provide an initiator with a way to explicitly control the execution of one or more tasks. A n application client invokes a task management function by means of a procedure call having the following format: Service response = Function name\(Object Identifier [,Input-1] [,Input-2-]... || [Output-1] [,Output-2]...\ Service Response: One of the following protocol-specific responses shall be returned: Function Complete : A l o g i cal unit response indicating that the requested function is complete . T h e t a s k m a n a g e r s h a l l u n c o n d i t i o n a l l y r e t u r n t h i s response upon completion o f a t a s k m a n a g e m e n t request supported by the logical unit or target device t o which the request was directed. Upon receiving a request to execute a n u n s u p p o r ted function, the task manager may return this response or th e Function Rejected response described below. Function Rejected : A n o p t i onal task manager response indicating that the operation is no t supported by the object to which the function was directed \(e.g., the logical unit or target device\ Service Delivery or Target Failure: T h e r e quest was terminated due to a service delivery failure or targe t malfunction. The target may or may not have successfully performed th e specified function. Each SCSI protocol standard shall define the actual events comprising each of the above service responses. The following task management functions are defined: A B O R T T A S K \( T a s k A d d r e s s | | \ - A b o r t the specified task. This function shall be supported if the logical unit supports tagged tasks and may be supported if the logical unit does not support tagged tasks \(see object definition 7\ A B O R T T A S K S E T \( L o g i c al Unit Identifier || \ - Abort all tasks in the task set for the requesting initiator. This function shall be supported by all logical units. C L E A R A C A \( L o g i c a l U n i t I d e n t i fier || \ - Clear auto contingent allegiance condition. This function shall be supported i f t h e l o g i c a l u n i t a c c e p t s a n N A C A b i t v a l u e o f o n e i n the CDB control byte and may be supported if the logical unit does not accept an NACA bit value of one in the CDB control byte \(see 5.1.2\ C L E A R T A S K S E T \( L o g i c a l U n i t I d e n t i f i e r | | \ - A b o r t a l l t a s k s i n t h e s p e c i fied task set. This function shall be supported b y a l l l o g i c al units that support tagged tasks \(see object definition 7\ support tagged tasks. T A R G E T R E S E T \( T a r g e t I d e n t i f i e r | | \ - R e s e t t h e t a r g e t d e v i c e a n d t e r m i nate all tasks in all task sets. All target devices shall support this function. TERMINATE TASK \(Task Address || \ - Terminate the specified task. Implementation of this function is a logical unit option. Argument descriptions: atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 59 Target Identifier: Target device identifier defined in object definition 5. Logical Unit Identifier: Logical Unit identifier defined in object definition 6. Task Address: Task address defined in object definition 7. I M P L E M E N T O R S N O T E S : T h e T A R G E T R E S E T , C L E A R T A S K S E T , ABORT TASK and ABORT TASK SET functions provide a means to terminate o n e o r m o r e t a s k s p r i o r t o n o r m a l c o m p l e t i o n . T h e T A R G E T R E S E T c o mmand clears all tasks for all initiators on all task sets of the target. The CLEAR TASK SET function terminates all tasks for all initiators on the specified task set of the target. An ABORT TASK SET function terminates all tasks for the initiator on the specified task set of the target. An ABORT TASK function terminates only the specified task. A l l S C S I - 3 protocol specifications shall provide the functionality needed for a task manager to implement all of the tas k management functions defined above. 6.1 ABORT TASK Function Call: Service Response = ABORT TASK\(Task Address || \ Description: T h i s f u n c t i o n s h a l l b e s u p p o r t e d b y a logical unit that supports tagged tasks and may be supported by a logical unit that does not support tagged tasks. T h e t a s k m a n a g e r s h a l l a b o r t the specified task if it exists. Previously established conditions, including MODE SELECT parameters, reservations, and auto contingent allegiance shall not be changed by the ABORT TASK function. If the logical unit supports this function, a response of Function Complete shall indicate that the task was aborted o r w a s n o t in the task set. In either case, the target shall guarantee that no further responses from the task are sent to the initiator. 6.2 ABORT TASK SET Function Call: Service Response = ABORT TASK SET\(Logical Unit Identifier || \ Description: This function shall be supported by all logical units. The task manager shall terminate all tasks in the task set which were created by the initiator. T h e t a s k m a n a g e r s h a l l p e r f o r m a n a c t i o n e q u i v a l e n t to receiving a series of ABORT TASK requests. All tasks from that i n i t i a t o r i n t h e t a s k s e t s e r v i c e d b y t h e l o g i cal unit shall be aborted. Tasks from other initiators or in other task sets shall n o t b e terminated. Previously established conditions, including MODE SELECT parameters, reservations, and aut o contingent allegiance shall not be changed by the ABORT TASK SET function. atend X3T10/994D revision 18 August 10, 1995 60 working draft SCSI-3 Architecture Model 6.3 CLEAR ACA Function Call Service response = CLEAR ACA \(Logical Unit Identifier || \ Description: T h i s f u n c t i o n s h a l l o n l y b e i m p l emented by a logical unit that accepts an NACA bit value of one in the CDB control byte \(see 5.1.2\ T h e i n i t i a t o r i n v o k e s C L E A R A C A t o c l e a r a n a u t o c o n t i n g e n t a l l e g i a n c e c o n d i t i o n f rom the task set serviced by the logical u n i t according to the rules specified in 5.6.1.2. The function shall always be terminated with a service response o f Function Complete . I f t h e t a s k m anager clears the auto contingent allegiance condition, any task within that task set may be complete d subject to the rules for task set management specified in clause 7. 6.4 CLEAR TASK SET Function Call: Service response = CLEAR TASK SET \( Logical Unit Identifier || \ Description: T h i s f u n c t i o n s h all be supported by all logical units that support tagged tasks \(see object definition 7\ and may b e supported by logical units that do not support tagged tasks. T h e t a r g et shall perform an action equivalent to receiving a series of ABORT TASK requests from each initiator. Al l t a s k s , f r o m all initiators, in the specified task set shall be aborted. The medium may have been altered by partiall y e x e c u t e d c o m m a n d s . A l l p e nding status and data for that logical unit for all initiators shall be cleared. No status shall b e s e n t f o r a n y t a s k . A u n i t attention condition shall be generated for all other initiators with tasks in that task set. When r e p o r t ing the unit attention condition the additional sense code shall be set to COMMANDS CLEARED BY ANOTHER INITIATOR. P r e v i o u s l y e s t a b l i s h e d c o n d i t i o n s , i n c l u d i n g M O D E S E L E C T parameters \(see the SPC standard\ contingent allegiance shall not be changed by the CLEAR TASK SET function. 6.5 TARGET RESET Function Call: Service Response = TARGET RESET \( Target Identifier || \ Description: This function shall be supported by all target devices. B e f o r e r e t u r n i n g a F u n c t i o n C o m p l e t e r e s p o n s e t h e target shall perform the hard reset functions specified in 5.6.6 and shall create a unit attention condition for all initiators as specified in 5.6.5. atend August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 61 6.6 TERMINATE TASK Function Call: Service response = TERMINATE TASK \(Task Address ||\ Description: Support for this function is a logical unit option. T h e T E R MINATE TASK function is invoked by the initiator to request task completion. A response o f F u n c t i o n C o m p l e t e i n d icates that the request has been accepted and does not imply that the referenced task has e n d e d . A s s u m i n g t h e t a s k e x i s t e d w h e n t h e T E R M I N A T E T A S K f u n ction was invoked, the initiator shall consider the task to continue in existence until one of the events specified in 5.4 is detected. W i t h t h e f o l lowing exceptions, the logical unit shall complete the specified task and return COMMAND TERMINATED s t a t u s . The sense key shall be set to NO SENSE. The additional sense code and qualifier are set to TAS K TERMINATED. If the work performed by the terminated task involves the transfer of data, the logical unit shall set the valid bit in the sense data to one and set the information field as follows: f\ I f t h e c o m m a n d d e s c r i p t o r b l o c k s p e cifies an allocation length or parameter list length, the information field shall be set to the difference \(residue\ g\ I f t h e command descriptor block specifies a transfer length field, the information field shall be set as defined in the REQUEST SENSE command \(see the SPC standard\ If an error is detected for the specified task, the logical unit shall ignore the TERMINATE TASK request and return a service response of Function Complete . I f t h e o p e r a t i o n r e q u e s t e d for the specified task has been completed but status has not been returned, the logical unit shall ignore the TERMINATE TASK request and return a service response of Function Complete . If the target does not support this function or is unable to stop the task, the target shall return a service response o f Function Rejected to the initiator and continue the task in a normal manner. T h e e f f e ct of a TERMINATE TASK request on the task set depends on the task set error recovery option specified in t h e c ontrol mode page \(see the SPC standard\ and on whether or not an auto contingent allegiance condition i s generated. I M P L E M E N T O R S N O T E : T h e T ERMINATE TASK function provides a means for the initiator to request the logical unit to reduce the transfer length o f t h e r e f e r e n c e d c ommand to the amount that has already been transferred. The initiator can use the sense data to determine the actual number of b y t e s o r b l o c k s t h a t h a v e b e e n t r a n s f e r r e d . T h i s f u n c t i o n i s n o r m a lly 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.7 Task Management Protocol Services T h e confirmed service described in this subclause is used by an application client to issue a task management remot e procedure call. The following arguments are passed: Object Address: A T a s k Address, Logical Unit Identifier or Target Identifier supplied by th e application client to identify the object to be operated upon. The initiator' s service delivery port will convert a Task Address to a Task Identifier before forwarding the request to the target. atend X3T10/994D revision 18 August 10, 1995 62 working draft SCSI-3 Architecture Model Object Identifier: A T a s k I d e n t i f i e r , L o g i c a l U n i t I dentifier or Target Identifier passed to the task manager by the protocol service indication. Function Identifier: Parameter encoding the task management function to be performed. A l l S C S I - 3 p rotocol specifications shall define the protocol-specific requirements for implementing the Send Tas k M a n a g e m e n t R e q u e s t p r o t o c o l s e r v i c e a n d t h e R e ceived Function-Executed confirmation described below. Support for the T a s k M anagement Request Received indication and Task Management Function Executed protocol service response by t h e S C S I - 3 p r o t o c o l s t a n d a r d i s o p t i o n a l . A l l S C S I - 3 I / O s y s t e m s s h a l l i m p l e m e n t t hese protocols as defined in the applicable protocol specification. The argument definitions correspond to those of clause 6. Request: Send Task Management Request \(Object Address, Function Identifier ||\ Indication received by task manager: Task Management Request Received \(Object Identifier, Function Identifier||\ Response from task manager: Task Management Function Executed \(Object Identifier, Service Response ||\ The Service Response parameter encodes a value representing one of the following \(see 6\ Function Rejected : The task manager does not implement the requested function. Function Complete : The requested function has been completed. Confirmation: Received Function-Executed \( Object Address, Service Response ||\ S i n c e t h e o bject identifier does not uniquely identify the transaction, there may be no way for an initiator to associate a c o n f i r m a t i o n w i t h a r e q u e s t . A n S C S I p r o t o c o l t h a t d o e s n o t provide such an association should not allow an initiator to have more than one pending task management request per logical unit. 6.8 Task Management Function Example The following diagram shows the sequence of events associated with a task management function. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ime T ime T ime T ime Application Client Application Client T ask Manager T ask Manager W aiting W aiting W orking W orking Activity Activity Activity Activity Initiator Initiator T arget T arget 4 4 3 3 2 2 1 1 taskmod.wp August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 63 Figure 22 : Task Management Request Processing The numbers in figure 22 Identify the events described below. 1. T h e a p p l i c a t i o n c l i e n t i s s u e s a t a s k m a n a g e m e n t r e q u e s t b y i n v o k i n g t h e Send Task Management Request protocol service. 2. T h e t a s k m a n a g e r i s n o t i f i e d t h r o u g h a T a s k M anagement Request Received indication and begins executing the function. 3. T h e task manager performs the requested operation and responds by invoking the Task Management Function E x e c u t e d p r o t ocol service to notify the application client. The Service Response parameter is set to a value o f Function Complete 4. A confirmation of Received Function-Executed is returned to the application client. atend X3T10/994D revision 18 August 10, 1995 64 working draft SCSI-3 Architecture Model 7 Task Set Management T h i s c l a u s e s p e c i f i e s t a s k s e t m a n a g e m e nt requirements in terms of task states, task attributes and events that cause task state transitions. T a s k b e h a v i o r , a s s p e c i f i e d h e r e i n , r e f e r s t o t h e f u n c t i o n i n g o f a t a s k a s o b served by an application client within the initiator -- i n c l u d i n g t h e r e s u l t s of command execution and interactions with other tasks. Examples of behavior not observable by the application client are the physical activity on the interconnect or the format of transmitted data packets associated with a c o m m a n d . T o d e f i n e t h ese and other aspects of behavior, SCSI-3 protocol and interconnect standards may impose other r e q u i r e m e n t s , o u t s i d e t h e s c o p e o f t h i s s t a n d a r d , w h i c h a r e r e l a t e d t o o b s e r v a b l e behavior within the protocol or interconnect layers. T h e r u l e s f o r task set management only apply to a task after it has been entered into the task set. A task shall be entered i n t o t h e t a s k s e t unless a condition exists which causes that task to be completed with a status of BUSY , R E S E R V A TION CONFLICT, TASK SET FULL, ACA ACTIVE or CHECK CONDITION \(if caused by the detection of a n o v e r l a p p e d c o m m a n d \ . A t a s k m a y a l s o b e completed in this manner because of a CHECK CONDITION status caused by certain protocol-specific errors. In these cases, the task shall be completed as soon as the condition is detected. 7.1 Terminology The following definitions are used extensively in this clause. suspended information: Information within the logical unit that is not available to a pending task. current task: A t a s k that has a data transfer protocol service request in progress \(se e 5 . 3.1\ or is in the process of returning command status. Each SCSI- 3 protocol standard shall define the protocol-specific conditions under whic h a task is considered a current task. pending task: Any task that is not a current task. 7.2 Task Management Events The following is a description of the events that drive changes in task state. All older tasks ended: A l l t a s k s h a v e e n d e d t h a t w e r e accepted into the task set earlier in time than the referenced task. All older Head of Queue All Head of Queue and Ordered tasks have ended that were accepted into and older Ordered tasks the task set earlier in time than the referenced task. ended: ACA : An auto contingent allegiance condition has occurred . task abort: One of the events described in subclause 7.3 has occurred. task completion: T h e d e v i c e server has returned a service response of Task Complete for the task \(see clause 5 and subclause 5.4\ task ended: A task has completed or aborted. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ask Created T ask Enabled T ask Completed T ask Dormant T ime Line Application Client observes system state A B C T ask Created and Enabled T ask Completed T ime Line A B C Case 1 Case 2 August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 65 Figure 23 : Example of Dormant Task Behavior ACA cleared: An ACA condition has been cleared. S u b c l a u s e 7 . 4 d e s cribes the events, changes in task state and device server actions for a Simple, Ordered, ACA or Head of Queue task. 7.3 Task Abort Events A Task Abort event is one of the following: h\ Completion of an ABORT TASK task management function directed to the specified task; i\ Completion of an ABORT TASK SET task management function under the conditions specified in subclause 6.2; j\ C o m p l e t i o n o f a C L E A R T A S K S E T t a s k m a n a g e m e n t f u n c t i o n r e f e r e n c i n g t h e task set containing the specified task; k\ An ACA condition was cleared and the QErr bit was set to one in the control mode page \(see the SPC standard\ l\ An ACA condition was cleared and the task had the ACA attribute; m\ A hard reset \(see 5.6.6\ n\ T h e r e t u r n o f a n E x e c u t e C o m m a n d s e r v i c e r e s p o n s e o f S e r v i c e D e l i v e r y or Target Failure as described in clause 5. o\ A power on condition. 7.4 Task States 7.4.1 Enabled A t a s k i n t h e E nabled state may become a current task and may complete at any time, subject to the task completio n c o n s t r a i n t s s p e c i f i e d i n t h e c o n t r o l m o d e p a g e \( s e e t h e S P C s t a ndard\ not complete or become a current task unless it is in the enabled state. E x c e p t f o r the use of target resources required to preserve task state, a task shall produce no effects detectable by th e a p p l i c a t i o n c l i e n t b e f o r e t h e t a s k ' s first transition to the Enabled state. Although, before entering this state for the first time, t h e t a s k may perform other activities visible to lower layers -- such as pre-fetching data to be written to the media -- thi s a c t i v i t y s h a l l n o t r e s u l t i n a d e t e c table change in device state as perceived by an application client. In addition, the behavior o f a c o m p l e t e d t a s k , a s d e f i n e d b y t h e c o m m a n d s i t h a s e x e c u t e d , s h a l l n o t b e a f fected by the task's states before it became enabled. atend X3T10/994D revision 18 August 10, 1995 66 working draft SCSI-3 Architecture Model F i g u r e 2 3 s hows the events corresponding to two task execution sequences. Except for the Dormant state between times A a n d B i n c a s e 1 , l o g i c a l u n i t c o n d i t i o n s a nd the commands executed by the task are identical. Assuming in each case the t a s k c ompletes with a status of GOOD at time C, the system state observed by the application client for case 1 shall b e indistinguishable from the state observed for case 2. 7.4.2 Blocked A t a s k i n t h e B l o c k e d s t a t e i s p r e v e n t e d from completing due to an auto contingent allegiance condition. A task in this state s h a l l n o t b e c o m e a c u r r e n t t a s k . While a task is in the Blocked state, any information the logical unit has or accepts for the task shall be suspended. 7.4.3 Dormant A t a s k i n t h e D o r m a nt state is prevented from completing due to the presence of certain other tasks in the task set. A task in this state shall not become a current task. While a task is in the Dormant state, any information the logical unit has or accepts for the task shall be suspended. 7.4.4 Ended A task in the Ended state is removed from the task set. 7.5 Task Attributes A task shall have one of the attributes defined below. 7.5.1 SIMPLE Task A t a s k h a v i n g t h e S i mple attribute shall be accepted into the task set in the Dormant state. The task shall not enter th e Enabled state until all older Head of Queue and older Ordered tasks in the task set have ended \(see 7.2\ 7.5.2 ORDERED Task A task having the Ordered attribute shall be accepted into the task set in the Dormant state. The task shall not enter the Enabled state until all older tasks in the task set have ended \(see 7.2\ 7.5.3 HEAD OF QUEUE Task A task having the Head of Queue attribute shall be accepted into the task set in the Enabled state. 7.5.4 ACA Task A t a s k h a v i n g the ACA attribute shall be accepted into the task set in the Enabled state. As specified in 5.6.1.1, there may be no more than one ACA task per task set. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE S2: Blocked S0: Dormant S1: Enabled S0:S1 S1:S2 ACA S2:S1 ACA Cleared S3: Ended Remove task from task set S0:S3 T ask Abort T ask End S1:S3 T ask Abort S2:S3 ACA Clear and: \173 \175 Simple T ask: All older Head of Queue and older Ordered tasks ended Ordered T ask: All older tasks ended August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 67 Figure 24 : Task States 7.6 Task State Transitions The task state diagram of figure 24 shows the behavior of a single task in response to an external event. T h e f o l lowing clauses describe task state transitions, actions and associated triggering events as they appear to a n a p p l i c a tion client. Although the logical unit response to events affecting multiple tasks, such as a Clear Task Set, may be d i f f e r e n t f r o m t h e response to an event affecting a single task, from the viewpoint of the application client the collectiv e behavior appears as a series of state changes occurring to individual tasks. I n t h e d i s c u s s i o n b e l o w , " d o r m a n t task" refers to a task in the Dormant state, "enabled task" to a task in the Enabled state, and so forth. 7 . 6 . 1 T r a n s i t i o n S 0 : S 1 \( O r d e r e d T a s k \ : P r o v i d e d an ACA condition does not exist, a dormant task having the ORDERED a t t r i b u t e s h a l l e n t e r t h e E n a b l e d s t a t e w h e n a l l o l d e r t a s k s h a v e e n d e d . T h i s t r a n s i tion shall not occur while an ACA condition is in effect for the task set. atend X3T10/994D revision 18 August 10, 1995 68 working draft SCSI-3 Architecture Model 7 . 6.2 Transition SO:S1 \(Simple task\ Provided an ACA condition does not exist, a dormant task having the SIMPL E a t t r i b u t e s h a l l enter the Enabled state when all older Head of Queue and older Ordered tasks have ended. This transition shall not occur while an ACA condition is in effect for the task set. 7.6.3 Transitions S0:S3, S2:S3: A task abort event shall cause the task to unconditionally enter the Ended state. 7.6.4 Transition S1:S2: An ACA condition shall cause an enabled task to enter the Blocked state. 7 . 6 . 5 T r a n s i t ion S1:S3: A task that has completed or aborted shall enter the Ended state. This is the only state transition that applies to an ACA task. 7.6.6 Transition S2:S1: When an ACA condition is cleared and the QErr bit is set to zero in the control mode page \(see the SPC standard\ 7.7 Task Set Management Examples T h e f o l l o w i n g s ubclauses give several task set management scenarios. These are valid for single or multi-initiator cases. T h a t i s , t h e i n t e r a c t i o n a m o n g tasks in a task set is independent of the initiator originating a task. The figure accompanying each example shows successive snapshots of a task set after various events, such as task creation or completion. In all c a s e s , t h e c o n s t r a i n t s o n t a s k completion order settable through the control mode page \(see the SPC standard\ effect. A t a s k s e t i s s h o w n a s a n o r d e r e d l i s t o r q u e u e o f t a s k s w i t h t h e h ead of the queue towards the top of the page. A new Head of Queue task always enters the task set at the head, displacing older Head of Queue tasks . Simple, Ordered and ACA tasks always enter the task set at the end of the queue. T a s k s , d e n o t e d b y r e c t a n g l e s , a r e n u m b e r e d i n a s c e n d i ng order from oldest to most recent. Fill, shape and line weight are used to distinguish task states and attributes as follows: Task attributes: a\ Simple tasks -- rounded corners; b\ Ordered and ACA tasks -- square corners and thin lines; c\ Head of Queue -- square corners and thick lines. Task states: a\ Enabled -- no fill; b\ Dormant -- grey \(50 percent fill\ c\ Blocked -- black. 7.7.1 Blocking Boundaries T h e c o n d i t i o ns preventing a dormant task from becoming enabled \(in the absence of an ACA condition\ are shown b y m e a n s o f \223blocking boundaries\224. Such boundaries appear as dotted horizontal lines with an arrow on both ends. Th e a c c o m p a n y i n g t e x t identifies the tasks causing the barrier condition. A task is impeded by the barrier if is between th e b o u n d a r y a n d t h e e n d o f t h e q u e u e . When no ACA is in effect, a task enters the Enabled state after all intervening barriers have been removed. B l o c k i n g b o u n d a r i e s a r e n o t s h o w n w h i l e a n A C A c o n d i t i o n e x i s t s . I n this case, the blocking effect of an ACA condition takes precedence. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE 1 2 T ask Set T ask Set Simple T ask 2 Simple T ask 4 Simple T ask 4 Head of Queue T ask 3 Head of Queue T ask 1 Blocking boundary task 1 Blocking boundary task 3 3 Simple T ask 2 Head of Queue T ask 1 Blocking boundary task 1 T ask Set Head of Queue T ask 1 Simple T ask 2 Blocking boundary task 1 August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 69 Figure 25 : HEAD OF QUEUE Tasks 7.7.2 HEAD OF QUEUE Tasks Figure 25 shows task set conditions when several Head of Queue tasks are executed, I n s n a p s h o t 1 t h e t a s k s e t i n i t i a lly contains one Head of Queue and one Simple task. As shown by the blocking boundary, simple task 2 is Dormant because of the older Head of Queue task. Snapshot 2 shows the task set after Head of Queue t a s k 3 a n d S i m p l e t a s k 4 a r e c r e a t e d . T h e n e w H e a d o f Q u e u e t a sk is placed at the front of the queue in the Enabled state, d i s p l a c i n g task 1. Snapshot 3 shows the task set after task 3 completes. Since the conditions indicated by the task 1 blocking boundary are still in effect, tasks 2 and 4 are held in the Dormant state. Figure 26 is the same as the previous example, except that task 1 completes instead of task 3. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ask Set Head of Queue T ask 1 Simple T ask 2 1 2 T ask Set Simple T ask 2 Simple T ask 4 Simple T ask 4 Head of Queue T ask 3 Head of Queue T ask 1 3 T ask Set Simple T ask 2 Head of Queue T ask 3 Blocking boundary task 1 Blocking boundary task 1 Blocking boundary task 3 Blocking boundary task 3 X3T10/994D revision 18 August 10, 1995 70 working draft SCSI-3 Architecture Model Figure 26 : HEAD OF QUEUE Tasks and Blocking Boundaries The completion of task 1 allows task 2 to enter the Enabled state. Simple task 4 is held in the Dormant state until task 3 completes.. 7.7.3 Ordered Tasks An example of Ordered and Simple task interaction is shown in figure 27. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ask Set Simple T ask 1 Ordered T ask 2 Ordered T ask 5 Ordered T ask 5 Simple T ask 3 Simple T ask 4 3 Ordered T ask 2 Simple T ask 3 Simple T ask 4 T ask Set 1 2 Simple T ask 3 Simple T ask 4 Ordered T ask 5 T ask Set Blocking boundary T asks 3 and 4, task 5 Blocking boundary tasks 1 and 2 Blocking boundary task 2 Blocking boundary task 2 Blocking boundary tasks 1 - 4, task 5 Blocking boundary tasks 2 - 4, task 5 August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 71 Figure 27 : Ordered Tasks and Blocking Boundaries The state of dormant tasks 2 through 5 is determined by the following rules: Tasks 2 and 5 -- An Ordered task cannot enter the Enabled state until all older tasks have ended. Tasks 3 and 4 -- A Simple task cannot enter the Enabled state until all older Head of Queue and older Ordered tasks have ended. These constraints are shown by the blocking boundaries in snapshot 1. I n s napshot 2, the completion of task 1 allows ordered task 2 to become Enabled. Since the initial constraints on tasks 3, 4 a n d 5 a r e s t i l l i n e f f e ct, these tasks must remain Dormant. As shown in snapshot 3, the completion of task 2 triggers two s t a t e c h a n g e s : - - n a m e l y , t h e t r a n s i t i o n s o f t a s k 3 a n d t a s k 4 t o the Enabled state. Task 5 must be held in the Dormant state until these tasks end. 7.7.4 ACA Task F i g u r e 2 8 s hows the effects of an ACA condition on the task set. This example assumes the QErr flag is set to zero in the c o ntrol mode page \(see the SPC standard\ atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ask Set Simple T ask 4 Simple T ask 1 4 Simple T ask 4 T ask Set Ordered T ask 3 Simple T ask 5 Simple T ask 1 ACA T ask 5 3 T ask Set Simple T ask 1 Simple T ask 4 2 Ordered T ask 3 Simple T ask 4 T ask Set Simple T ask 1 Simple T ask 2 1 Ordered T ask 3 Blocking boundary tasks 1 and 2, task 3 Blocking boundary task 3 X3T10/994D revision 18 August 10, 1995 72 working draft SCSI-3 Architecture Model Figure 28 : ACA Task Example T h e completion of task 2 with CHECK CONDITION status causes task 1 to enter the Blocked state shown in snapshot 2. I n s n a p s h o t 3, Ordered task 3 is aborted and ACA task 5 is created to handle the exception. Once the ACA condition i s cleared, \(snapshot 4\ Simple task 1 can reenter the Enabled state. Since there are no Head of Queue or Ordered tasks older than task 4, it too can be placed in the Enabled state. 7.7.5 Deferred Task Completion I n t h e e x a m p l e o f f i g ure 29, the logical unit must defer task completion in response to an exception condition until the task e n t e r s t h e E n a b l e d state. In this case, completion is caused by a TERMINATE TASK task management function directed t o a d o r m a n t t a s k . T h e e x a m p l e w o u l d a l s o a p p l y t o o t h er cases, such as a task to be completed with CHECK CONDITION status because of an error in a CDB parameter. atend c Composite [Error: PathTooComplex; OffendingCommand: AnyPaintingOperator]\n 0 0 Composite Cyan Magenta Yellow Black COMPOSITE T ask Set T ask Set Simple T ask 3 ORDERED T ask 1 Simple T ask 2 2 1 Simple T ask 3 Simple T ask 2 3 T ask Set Simple T ask 2 Blocking boundary task 1 Begin annexes after this comment August 10, 1995 X3T10/994D revision 18 working draft SCSI-3 Architecture Model 73 Figure 29 : Example of Deferred Task Completion I n s n a p s h o t 1 , a T E R M I N A T E T A S K t a s k m a n a g e ment request has been directed to Dormant task 3. Because of Ordered task 1, task 3 cannot enter the Enabled state and therefore cannot complete. The eventual completion of task 1 allows t a s k s 2 a n d 3 t o b e c o m e e n a b l e d a s s h o w n i n s n a p s h o t 2. The pending TERMINATE TASK request can now be executed. The resulting auto contingent allegiance condition causes task 2 to enter the Blocked state shown in snapshot 3. B e c a u s e t a s k s i n t h e E n a b l e d s t a t e m a y c o m p l e t e in any order Simple task 2 may complete before task 3. In that case, the following alternate outcomes are possible: a\ S i m p l e t a s k 2 may complete with GOOD status, followed by the completion of task 3 with CHECK CONDITIO N status; b\ Simple task 2 may complete with CHECK CONDITION status; task 3 is placed in the Blocked state.