ANSI INCITS 294-1996 Information Technology - Serial Storage Architecture - SCSI-2 Protocol (SSA-S2P).pdf

1、ANSI INCITS 294-1996 (2001)(formerly ANSI X3.294-1996 (2001)for Information Technology Serial Storage Architecture SCSI-2 Protocol (SSA-S2P)ANSIX3.294-1996American National Standardfor Information Technology Serial Storage Architecture SCSI-2 Protocol (SSA-S2P)SecretariatInformation Technology Indus

2、try CouncilApproved November 29, 1996American National Standards Institute, Inc.AbstractThis standard describes the SCSI-2 mapping protocol (SSA-S2P) to be used on theSerial Storage Architecture-Transport Layer 1 (SSA-TL1).AmericanNationalStandardApproval of an American National Standard requires re

3、view by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgment of the ANSI Board of StandardsReview, substantial agreement has been reached by directly and materiallyaffected interes

4、ts. Substantial agreement means much more than a simplemajority, but not necessarily unanimity. Consensus requires that all views andobjections be considered, and that a concerted effort be made toward theirresolution.The use of American National Standards is completely voluntary; their existencedoe

5、s not in any respect preclude anyone, whether he has approved the standardsor not, from manufacturing, marketing, purchasing, or using products, processes,or procedures not conforming to the standards.The American National Standards Institute does not develop standards and will inno circumstances gi

6、ve an interpretation of any American National Standard.Moreover, no person shall have the right or authority to issue an interpretation ofan American National Standard in the name of the American National StandardsInstitute. Requests for interpretations should be addressed to the secretariat orspons

7、or whose name appears on the title page of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National StandardsInstitute require that action be taken periodically to reaffirm, revise, or withdrawthis standard. Purchas

8、ers of American National Standards may receive currentinformation on all standards by calling or writing the American National StandardsInstitute.Published byAmerican National Standards Institute11 West 42nd Street, New York, New York 10036Copyright 1996 by Information Technology Industry Council (I

9、TI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of ITI, 1250 Eye Street NW,Washington, DC 20005.Printed in the United States of AmericaiForeword .iiiIntroductionvi1 Scope and family of st

10、andards11.1 SSA-S2P .11.2 SSA-TL111.3 SSA-PH1.21.4 SSA-S3P .21.5 SSA-TL221.6 SSA-PH2.22 Normative references.23 Definitions, symbols and abbreviations .23.1 Definitions .23.2 Symbols and abbreviations.34 General .44.1 Overview .44.2 Conventions 55 Frames66 SSA-S2P message structure 66.1 Summary of S

11、SA-S2P SMSs 76.2 SMS validation.86.3 SMS buffer full condition 96.4 Limitation on task management SMSs 96.5 TAG field values 96.6 SCSI COMMAND SMS .106.7 SCSI STATUS SMS .126.8 ABORT TAG SMS 136.9 ABORT SMS146.10 CLEAR QUEUE SMS146.11 DEVICE RESET SMS.156.12 CLEAR SCA CONDITION SMS.166.13 SCSI RESPO

12、NSE SMS 177 Transport related items 187.1 Spindle synchronization .187.2 Unit attention flag in the Initiator Table 187.3 Tag interaction between SSA-TL and SSA-S2P.187.4 Effects of reset conditions 198 SSA-S2P changes from parallel SCSI-2 198.1 Untagged queuing is emulated .198.2 Serial Contingent

13、Allegiance Condition .198.3 Concurrent data transfers from a single target.208.4 Multiple logical paths208.5 Unit attention .208.6 Optional SCSI-2 features not supported in SSA-S2P .218.7 Mode Page parameter differences 21ContentsPageiiTables1 Bit ordering in a byte . 52 Generic SMS format for initi

14、ator generated SSA-S2P SMSs.73 Generic SMS format for target generated SSA-S2P SMSs .74 Summary of SSA-S2P SMSs 75 SCSI COMMAND SMS .106 QUEUE CNTL field values117 SCSI STATUS SMS .128 Meaning of flag and link bits .139 ABORT TAG SMS 1310 ABORT SMS1411 CLEAR QUEUE SMS .1512 DEVICE RESET SMS.1613 CLE

15、AR SCA CONDITION SMS.1714 SCSI RESPONSE 1715 RETURN CODE values for the SCSI RESPONSE SMS18Figure1 Relationship of the SSA standards1AnnexesA SCSI Status .23B Parallel SCSI-2 message to SSA-S2P SMS conversion .25C Some differences between SSA-S2P and parallel SCSI-2 28D Protocol services model .30E

16、Transport service handling .43PageiiiThis standard was developed by Task Group X3T10.1 of AccreditedStandards Committee X3 during 1993-96. The standards approval processstarted in 1995. This standard includes five annexes. Annex A is normative. Annexes B toE are informative and are not considered pa

17、rt of this standard.Requests for interpretation, suggestions for improvement and addenda, ordefect reports are welcome. They should be sent to the X3 Secretariat,Information Technology Industry Council, 1250 Eye Street, NW, Suite 200,Washington, DC 20005-3922.This standard was processed and approved

18、 for submittal to ANSI byAccredited Standards Committee on Information Technology, X3.Committee approval of the standard does not necessarily imply that allcommittee members voted for its approval. At the time it approved thisstandard, the X3 Committee had the following members:James D. Converse, Ch

19、airDonald C. Loughry, Vice-ChairKate McMillan, SecretaryOrganization Represented Name of RepresentativeAMP, Inc. Ben BennettEdward Kelly (Alt.)Apple Computer, IncDavid K. MichaelJerry Kellenbenz (Alt.)ATb) Command descriptor blocks;c) Status byte;d) Sense bytes.Except where necessary for clarity the

20、 above functions are not described in this standard (please referto the ANSI SCSI-2 standard for information). SSA-S2P concentrates on mapping the followingaspects of parallel SCSI-2:a) Bus functions;b) Addressing;c) Messages.SSA-S2P supports Webs containing strings, loops, and switches. The concept

21、s of initiator, target, andLogical Unit are retained although SSA-S2P supports larger configurations than parallel SCSI-2.Initiators and targets may be freely mixed throughout the Web. Each node may have from 1 to 126physical ports.SSA-S2P offers the following benefits compared to the parallel SCSI

22、bus:a) Open-ended Webs with alternative paths for availability and performance;b) Full-duplex communication with spatial reuse on strings and loops;ANSI X3.294-19965c) Frame multiplexing;d) No overhead for arbitration, disconnection, or reselection;e) Integrated spindle synchronization for array app

23、lications;f) Fewer initiator-target exchanges;g) Concurrent I/O processes on the same device or different devices;h) Out-of-order data transfers.Restrictions:a) Untagged queuing may be simply emulated with Tagged Queuing. In SSA, the targeteffectively disconnects after each frame because of frame mu

24、ltiplexing. Hence each commandshall have a tag for identification. Untagged command queuing may be simply emulated byhaving the initiator have only one outstanding command, re-use the same tag, and use thesimple queue type;b) SSA-S2P uses Serial Contingent Allegiance. The SCSI-2 concept of Contingen

25、t Allegiancedoes not work for SSA since the next command clears the Contingent Allegiance condition,and the next command may be in the SSA Web prior to the status being received by theinitiator. Therefore SSA-S2P adopts the concept of Serial Contingent Allegiance where theSerial Contingent Allegianc

26、e condition shall be explicitly cleared by a CLEAR SCACONDITION SMS.4.2 ConventionsCertain words and terms used in this standard have a specific meaning beyond the normal Englishmeaning. These words and terms are defined in the text with the first letter capitalized. Lower case isused for words havi

27、ng the normal English meaning.Fields containing only one bit are usually referred to as the “named” bit instead of the “named” field.When a bit is set, its value is 1. When a bit is cleared, its value is 0.Numbers that are not immediately followed by lower-case “b“ or “h“ are decimal values.Numbers

28、immediately followed by lower-case “b“ (xxb) are binary values.Numbers immediately followed by lower-case “h“ (xxh) are hexadecimal values.Decimal fractions are indicated with a comma (e.g., two and one half is represented as “2,5”). Decimalnumbers having a value exceeding 999 are represented with a

29、 space (e.g., 24 255).Table 1 illustrates the bit ordering used within a byte in SSA-S2P.Table 1 Bit ordering in a byteBit 7654321Bit 0msb lsbReserved bits, fields, bytes, and code values are set aside for future standardization. Their use andinterpretation may be specified by future extensions to t

30、his standard. A reserved bit, field, or byte shallbe set to zero, or in accordance with a future extension of this standard. Reserved bits, fields, bytes,or reserved field values shall be ignored when cut-through routing a frame. A destination node thatreceives a reserved bit, field, or byte that is

31、 not zero, or receives a reserved code value shall terminatethe SMS as described in 6.2.ANSI X3.294-19966Ignored bits, fields, or bytes shall be ignored by the receiving node. Any value is considered valid.SMS names are shown as all capital letters, such as SCSI STATUS SMS. Field names are shown ass

32、mall capital letters, such as the STATUS field. Field values are shown as all capital letters, such as theSTATUS field QUEUE FULL value. Variables are shown in italics.The byte ordering convention is Big Endian (i.e., the most significant byte of a number is sent first).5 FramesAll SSA-S2P SMSs and

33、data are transmitted in Application frames whose format is described in SSA-TL. A Data frame is an Application frame with a non-zero Channel component.To improve system bandwidth, individual frames are delivered without end-to-end acknowledgment(this mode of delivery is referred to as datagram servi

34、ce). Such acknowledgment, when required, ismore efficient if performed by the higher level protocol on protocol-specific transactions, such as anS2P SCSI command or task management function.6 SSA-S2P message structureSMSs are used to communicate control information between the target and the initiat

35、or. They aretypically used for commands, status, and controlling I/O processes. Some SSA-S2P SMSs are similarin function to SCSI messages but there is not a one-to-one mapping and they should not be confused.The ADDRESS field in an SMS contains the Path component (address to the destination node) fo

36、llowedby the byte 00h to select the SMS Channel component. The length of the DATA field depends on theparticular SMS. Each SMS shall be fully contained in a single frame.SSA-S2P SMS frames are identified by a Channel component value of 00h, and the first byte (byte 0)of the DATA field containing SSA

37、-S2P SMS CODE value of 82h. The second byte (byte 1) of the DATAfield of SSA-S2P SMSs contains the S2P CODE field identifying the function of SSA-S2P SMS.The SCSI COMMAND SMS optionally contains a 2-byte CHANNEL field. This contains the Channelcomponent for the ADDRESS field of data frames. If the C

38、hannel component is a single byte, theCHANNEL field contains the Channel component left aligned, with the second byte padded with anyvalue by the source node and ignored by the destination node.All SMSs contain a 2-byte TAG field that is used to relate replies to the original request. The TAG fieldv

39、alue is assigned by the initiator and it shall be unique among all the TAG field values that are currentlyactive from that initiator on any target or Logical Unit throughout the Web. Effectively the TAG fieldidentifies the target, LUN, and Queue-tag components of the SCSI-2 nexus. (The initiator and

40、 logicalpath are identified by the RETURN PATH ID field in the SMS.)A target always replies to a given SMS using the same logical path from which it received the SMS.Any SMS received with a valid SSA-S2P SMS code whose DATA field meets any of the error conditionsin 6.2 shall cause the specified erro

41、r response. An SMS has a maximum length of 32 bytes. Only thebytes defined in the appropriate SMS are required, however the SMS may be padded up to a totallength of 32 bytes. The source node shall pad (if any) with zeros, and the destination node shall ignoreany pad bytes.ANSI X3.294-19967Table 2 de

42、fines the generic structure of an SSA-S2P SMS generated by the initiator.Table 2 Generic SMS format for initiator generated SSA-S2P SMSsByteBit 7654321Bit 00 SMS CODE (82h)1 S2P CODE2 TAG3 TAG4 RETURN PATH ID5 RETURN PATH ID6 RETURN PATH ID7 RETURN PATH ID8 LUNTAR LUNTRN9 (Depends on the SMS)up to 3

43、1 (Depends on the SMS)All SMSs from the initiator to the target contain a RETURN PATH ID field, a value supplied by the targetduring configuration to identify the logical path to the appropriate initiator (see SSA-TL).The LUNTAR bit and LUNTRN field need not be present, but if present shall reside i

44、n byte 8.Table 3 defines the generic structure of an SSA-S2P SMS generated by the initiator.Table 3 Generic SMS format for target generated SSA-S2P SMSsByteBit 7654321Bit 00 SMS CODE (82h)1 S2P CODE2 TAG3 TAG4 (Depends on the SMS)up to 31 (Depends on the SMS)The following subclauses define the SMSs

45、that are used by SSA-S2P.6.1 Summary of SSA-S2P SMSsTable 4 shows a summary of all SSA-S2P SMSs.Table 4 Summary of SSA-S2P SMSsSMS name Byte 0 Byte 1 SMS FRAME TYPE Node type supportSMS CODE S2P CODE Sent by Received bySCSI RESPONSE 82h 03h APPLICATION target initiatorSCSI COMMAND 82h 10h APPLICATIO

46、N initiator targetSCSI STATUS 82h 11h APPLICATION target initiatorABORT TAG 82h 30h APPLICATION initiator targetABORT 82h 31h APPLICATION initiator targetCLEAR QUEUE 82h 32h APPLICATION initiator targetDEVICE RESET 82h 33h APPLICATION initiator targetCLEAR SCA CONDITION 82h 34h APPLICATION initiator

47、 targetANSI X3.294-199686.2 SMS validationPrior to the SSA-S2P protocol layer receiving an SMS, the transport layer has validated the SMS CODEfield to be 82h. Each SMS then undergoes three levels of validation as described in the following threesubclauses.6.2.1 SMS code validationAfter the transport

48、 layer checks the SMS for validity, the SSA-S2P layer shall perform validity checkson byte 1, the S2P CODE, in the following order. If the Asynchronous Alert process is invoked then theSMS is terminated without any other response:a) If the S2P CODE is not a value supported in table 4, then invoke th

49、e Asynchronous Alert processwith an UNKNOWN SMS ALERT CODE field (see SSA-TL for a description of ASYNC ALERTSMS format);b) If the S2P CODE is supported in table 4, but the node does not match the corresponding type(initiator or target), then invoke the Asynchronous Alert process with an UNKNOWN SMSALERT CODE field;c) If table 4 matches the S2P CODE of the SMS, but the FRAME TYPE field does not have a value ofAPPLICATION then invoke the Asynchronous Alert process with an SMS UNKNOWN ALERTCODE field;d) If the S2P CODE corresponds to the ABORT, ABORT TAG, CLEAR QUEUE, DEVICE RESE