draft proposed	X3T10
American National Standard	992D
Revision 19
Sept 19, 1994



Information Technology -
SCSI-3 Serial Bus Protocol (SBP)



This is 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 
comments received during public review and its approval as a standard.

Permission is granted 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 reserved. Any commercial or for-profit replication or republication of this 
document is strictly prohibited.



ASC X3T10 Technical Editors:
	Gerald A. Marazas			Scott Smyers		Ronald K. Roberts
	IBM Corporation			Sony Corp		Maxtor Corp.
	1000 NW 51st Street		3300 Zanker Rd		211 River Oaks Parkway
	Boca Raton, FL 33432		San Jose, CA 95134	San Jose, CA 95134
	Mail Stop 5432			Mail Stop SJ3C!		Mail Stop C217
	TEL:	(407) 982-4423		(408) 955-4573		(408) 432-4322
	FAX:	(407 982-0067		(408) 			(408) 432-4239
marazas@bcrvmpc2.vnet.ibm.com		scotts@lsi.sel.sony.com 	rkroberts@aol.com


Reference number
ISO/IEC ***** : 199x
ANSI X3.*** - 199x
Printed Sept 19, 1998

Other Points of Contact:

X3T10 Chair
X3T10 Vice-Chair

John B. Lohmeyer
Lawrence J. Lamers

NCR Corporation
Adaptec

1635 Aeroplaza Drive
691 South Milpitas Blvd.

Colorado Springs, CO 80916
Milpitas, CA 95035
Voice:
(719) 573-3362
(408) 957-7817
Fax:
(719) 597-8225
(408) 957-7193
Email:
john.lohmeyer@ftcollinsco.ncr.com
ljlamers@adaptec.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
IEEE 1394 Reflector
Internet address for subscription:	bob.snively@eng.sun.com
Internet address for distribution:	IEEE 1394@scsi.eng.sun.com
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
This document describes a command and status delivery protocol for controlling the operation of devices 
attached to an IEEE 1394 Serial Bus physical interface.  This protocol is based on a mapping of Parallel SCSI 
commands and messages to the IEEE 1394 environment.

PATENT STATEMENT
CAUTION: The developers of this standard have requested that holder's of patents that may be required for 
the implementation 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.
As of the date of publication of this standard and following 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 by the developer or the publisher in respect to any standard it processes.  No representation is 
made or implied that licenses are not required to avoid infringement in the use of this standard.

Document differences Rev 17 vs Rev 18
Rev 18 has revised or deleted the following clauses:
Annex B.(Rev 17) Device drive considerations (informative) has been removed.
Annex D. (Rev 17) Examples of CDS delivery (informative) has been removed. 
Remaining annex's have been re-numbered and re-ordered
Clause 5 has been modified for clarification's and comment response
Clauses 6 and 7 have been rewritten based on comments received from reviews of revision 16 and 17. 
Clause 10 has been modified to incorporate isochronous transfer controls, also identifies rules for handling 
CDB's based on comments received.
Annex C has had additional information added.


Contents
Document differences Rev 17 vs Rev 18	2
Contents	3
Foreword	6
1.0.   Scope	8
2.0.   Normative references	8
3.0.   Definitions, symbols and abbreviations	8
3.1.   Definitions	8
3.2.   Symbols and Abbreviations	10
4.0.   General	10
4.1.   Conventions	11
5.0.   Model of serial bus protocol	12
5.1.   IEEE 1394 MEMORY MAP and ADDRESS SPACE	12
5.1.1.   Configuration ROM	12
5.1.2.   Command FIFO	12
5.2.   Command Data Structures (CDS)	12
5.2.1.   TAP slots	13
5.2.2.   CDS chains	13
5.2.3.   CDS movement	13
5.2.4.   Task sets	14
5.2.5.  Time stamp	14
5.3.  Data transfers	14
5.3.1.  Asynchronous transfers	15
5.3.2.  Isochronous transfers	15
5.4.  Auto sense	15
5.5.  Asynchronous event notification	15
5.6.  Exception handling	16
6.0.  SCSI-3 Architecture model services	16
6.1.   Command execution services	16
6.1.1.   Tap protocol	16
6.1.2.   Fetch protocol	16
6.2.   Data transfer services	16
6.2.2.   Data transfer from initiator to target	17
6.3.   Task management services	17
6.3.1.   Abort task	17
6.3.2.   Abort task set	17
6.3.3.   Clear task set	17
6.3.4.   Clear auto contingent allegiance	18
6.3.5.   Target reset	18
6.3.6.   Terminate task	18
6.4.   Exception and error processing	19
6.4.1.   Tap transfer exceptions	19
6.4.2.   Fetch transfer exceptions	19
6.4.3.   Asynchronous data transfer exceptions	19
6.4.4.   Isochronous data transfer exceptions	19
7.0.   SBP Transaction management	19
7.1   Transaction services	19
7.1.1.   Transaction data request (TR_DATA.request)	20
7.1.2.   Transaction data confirmation (TR_DATA.confirmation)	20
7.1.3.   Transaction data indication (TR_DATA.indication)	20
7.1.4.   Transaction data response (TR_DATA.response)	20
7.2.   Tap transaction	20
7.3.   Fetch transaction	21
7.4.   Asynchronous data transfer	22
7.4.1.   Application data transfer target to/from initiator	22
7.4.2   Login data transfer from target to initiator	23
7.4.3.   Status data transfer from target to initiator	23
7.5.   Isochronous data transfers	24
7.5.1.   Link layer services	24
7.5.2.   Isochronous status reporting	24
7.5.3.   Ignore and continue	25
7.5.4.   Report and continue	25
7.5.5.   Report and stop	26
8.0.   Target memory	27
8.1.   Configuration ROM	27
8.2.   Asynchronous FIFO's	28
8.2.1.   Asynchronous login FIFO	28
8.2.2.   Asynchronous normal FIFO	28
8.2.3.   Asynchronous urgent FIFO	29
8.2.4.   Asynchronous ACA FIFO	29
8.3.   Isochronous FIFO's	29
8.3.1.   Isochronous login FIFO	29
8.3.2.   Isochronous normal FIFO	29
8.3.3.   Isochronous urgent FIFO	30
8.3.4.   Isochronous ACA FIFO	30
9.0.   Initiator memory	31
9.1.   Status FIFO	31
9.2.   CDS sense buffer	32
9.3.   Asynchronous event buffer	33
10.0.   Command data structures	34
10.1.   General CDS format	34
10.1.1.   CDS codes field	35
10.1.2.   Data transfer control field	36
10.2.   SCSI CDS formats	36
10.2.1.   SCSI CDS	36
10.2.2.   Isochronous SCSI CDS	40
10.3.   LOGIN CDS	41
10.4.   MANAGEMENT CDS	43
10.5   Isochronous control CDS	44
11.0.   Control procedures	46
11.1.   Login procedure	46
11.1.1.   Asynchronous login procedure	46
11.1.2.   Isochronous login procedure	46
11.1.3.   Tap slot allocation procedure	47
11.2.   Logout procedure	47
11.2.1.   Asynchronous logout	47
11.2.2.   Isochronous logout	48
11.3.   Sign-in procedure	48
Annex A   Configuration ROM (informative)	49
12.0.   Scope	49
12.1.   First quadlet	50
12.2.   Bus information block	51
12.3.   Root directory	51
12.4.   Node unique ID leaf	51
12.5.   Unit directory	52
12.6.   Unit dependent directory	52
12.7.   Asynchronous  and isochronous login FIFOs	52
Annex B  Examples (informative)	53
13.0.   Command processing	53
13.1.   Target read command	53
13.2.   Target multiple read commands	54
Annex C  ISOCHRONOUS TRANSFERS (Informative)	55
14.0.   Isochronous Transfers	55
14.1.   Definitions	55
14.2.   Isochronous Data Packetization	55


Figures
Figure 3 - Block diagram of Serial SCSI Device	27
Figure A-1 - Configuration ROM Layout	49
Figure B-1 - Target read command	53
Figure B-2 - Target multiple read commands	54


Tables
Table 1 - Bit ordering in a byte	11
Table 2 - Byte ordering within a quadlet	11
Table 3 - Error log entry	26
Table 4 - Isochronous status codes	26
Table 5 - Unit Directory	27
Table 6 - Unit Dependent Directory	28
Table 7 - Status block	31
Table 8 - CDS status	31
Table 9 - SBP status	32
Table 10 - CDS sense data format	32
Table 11 - Status quadlet	32
Table 12 - Valid flags field	33
Table 13 - Command data structure format	34
Table 14 - CDS codes field	35
Table 15 - CDS identifier	35
Table 16 - Tap type	35
Table 17 - CDS type field	36
Table 18 - Data transfer control field	36
Table 19 - Data transfer rate	36
Table 20 - SCSI CDS	37
Table 21 - Task codes field	37
Table 22 - Task attribute	37
Table 23 - Protocol flags field	38
Table 24 - Scatter/gather list	38
Table 25 - ISOCHRONOUS SCSI CDS	40
Table 26 - Protocol flags field	40
Table 27 - LOGIN CDS	41
Table 28 - Login flags field	41
Table 29 - LOGIN data format	42
Table 30 - Management CDS	43
Table 31 - Management flags field	43
Table 32 - SBP flags field	43
Table 33 - Isochronous Control CDS	44
Table 34 - Action Field	44
Table 35 - Stream Event Field	45
Table 36 - Error Reporting Field	45
Table A-1 - Example of SBP configuration ROM entries	50


Foreword
Clause 1 defines the scope of the Serial Bus Protocol
Clause 2 specifies the normative references
Clause 3 defines the definitions, symbols and abbreviations
Clause 4 contains general information
Clause 5 contains the model of serial bus protocol
Clause 6 defines the SCSI-3 services
Clause 7 defines the SBP transaction management 
Clause 8 defines the target memory and command FIFO's
Clause 9 defines the initiator memory and status blocks
Clause 10 defines the command data structures 
Clause 11 defines the control procedures
Annexes A, B, C and D are informative.

Introduction
A major goal  of this protocol is to define a model acceptable to device vendors, looking for an evolution from 
parallel SCSI, and systems designers looking for opportunities to more fully exploit the capabilities inherent to 
the IEEE 1394 I/O bus.
One element of SBP is that the SCSI CDB's are contained in a larger data structure called a CDS.  In addition 
to the CDB, the CDS contains additional information, such as  that used to link a sequence of CDS's into a 
chain and pointers into initiator memory for various other operations. 
The protocol described in this document has the following functional capabilities:
1.	  Allows the initiator to form a chain of commands without limitation of the queue depth in a target.
2.	  Target does not need to interrupt the processing of one prior command in order to queue a
      subsequent command.
3.  Ability to design target devices that have varying levels of support for command queuing or
      command processing without affecting the design of the initiator.  
4.	   Distribute the DMA context handling from the initiator adapter to the targets to minimize device
      and adapter complexity for higher subsystem performance.
This protocol has the following elements to ease the transition to a Serial SCSI:
1.  Integrates SCSI command descriptor blocks (CDB) within the SBP command data structure (CDS).
2.	  Follows the SCSI-3 Architectural Model.
In striking a balance between support for existing parallel SCSI functions, and providing a growth path to 
exploitation of new features of the serial SCSI environment, a new fixed length CDS has been defined.  This 
CDS provides support for advanced features of today's SCSI such as automatic sense data reporting and 
scatter-gather host data buffer handling.  Support is provided for interesting new features of the IEEE 1394 
High speed Serial Bus such as isochronous data transfer.  SBP does not require atomic or "locked" memory 
operations for list pointer update or management.

Information Processing Systems - SCSI-3 Serial Bus Protocol
1.0.   Scope
This document defines a protocol to deliver SCSI command, data, and status over an IEEE 1394 High 
Performance Serial Bus physical interface.  This document conforms to the SCSI-3 Architectural Model (SAM) 
and the IEEE 1212 Control and Status Registers standards. All devices implementing SBP shall meet the 
mandatory requirements of IEEE 1394, IEEE 1212 and SAM.
2.0.   Normative references
This standard references the following standards:
IEEE 1394 High Performance Serial Bus
IEEE 1212 Control and Status Registers
SCSI-3 Architecture Model 
SCSI-3 Command Set documents
All references made in this standard to a Command Descriptor Block (CDB) refer to those CDB's and CDB 
formats defined in the SCSI-2 or SCSI-3 standards documents.
3.0.   Definitions, symbols and abbreviations
3.1.   Definitions
3.1.1.	acquire:  The act of transferring a CDS from an initiator to a target.  This can be done with a fetch 
or a tap.
3.1.2.	asynchronous ACA FIFO:  An address to which a CDS is sent during the auto-contingent 
allegiance condition to deliver ACA tagged commands.
3.1.3.	asynchronous data transfer:   A data transfer mode of the High Performance Serial Bus that is 
characterized by unscheduled, acknowledged delivery of data packets over the IEEE 1394 bus.  
3.1.4.	asynchronous login FIFO:  An address to which a CDS is sent during the asynchronous login 
procedure.
3.1.5.	asynchronous normal FIFO:  An address to which a CDS is sent that the initiator expects to have 
a normal execution.
3.1.6.	asynchronous urgent FIFO:  An address to which a CDS is sent that the initiator expects to have 
priority execution.
3.1.7.	baseline CDS:  The first 64 bytes of a CDS.
3.1.8.	chain:  A list of CDS's connected together via a forward pointer from one CDS to the next following 
CDS.
3.1.9.	command data structure (CDS):  A structure that an initiator creates to describe an operation to be 
performed by a target.
3.1.10.	command FIFO:  A write only data structure in the target at a fixed address within the target's 
address space.  Initiators write CDS's to the address of a command FIFO as part of the command delivery 
protocol.
3.1.11.	cooperative multi-initiator environment: a collection of initiators such that each and every one of 
them restrict their usage of Tap Slots at a given target to no more than the number of Tap Slots allocated to 
them by that target at login time.
3.1.12.	displacement: The offset of  a bit  within a field.  For example, a displacement of zero indicates the 
leftmost or most significant bit of a field.
3.1.13	enter policy:  The rules governing the entering of commands to a task set.
3.1.14	extended CDS:  The portion of the CDS following the first 64 bytes.
3.1.15	fetch:  A read operation by a target to acquire a CDS.
3.1.16	initiator identifier:  An 8-bit value assigned by the login procedure.  See the SCSI-3 Architectural 
Model for definition.
3.1.17.	isochronous ACA FIFO:  An address to which a CDS is sent during the auto-contingent allegiance 
condition to deliver ACA tagged commands.
3.1.18.	isochronous data transfer:  A data transfer mode of the High Performance Serial Bus that is 
characterized by scheduled, non-acknowledged delivery of data packets over the bus.
3.1.19,	isochronous login FIFO:  An address to which a login CDS is sent used during the isochronous 
login procedure.
3.1.20.	isochronous normal FIFO:  An address to which a isochronous CDS is sent that the initiator 
expects to have normal execution.
3.1.21.	isochronous urgent FIFO:  An address to which a isochronous CDS is sent that the initiator 
expects to have priority execution.
3.1.22.	logical unit number:  The contents of a field in the CDS which identifies logical units in the target.  
See the SCSI-3 Architectural Model for definition.
3.1.23.	login:  The procedure by which an initiator obtains the addresses of the appropriate FIFO's and  a 
identifier.
3.1.24.	node identifier:  The IEEE 1394 node_ID.
3.1.25.	sign-in:  A procedure by which an initiator requests notification of asynchronous events.
3.1.26.	status block:  A data structure returned by the target that contains status information for a 
command.
3.1.27.	status FIFO:  An address in the initiator to which the target returns the status block.
3.1.28.	stream identifier:   an 8-bit value assigned by the isochronous login procedure.
3.1.29.	tag value:  The 64-bit address of a CDS. See the SCSI-3 Architectural Model for definition.
3.1.30.	tap:  A  write operation by an initiator to transfer the baseline portion of the first CDS of a chain.
3.1.31.	tap slot:  A resource within a target used to hold the baseline portion of a CDS.
3.1.32.	target identifier:   the 64-bit address of the unit dependent directory. See the SCSI-3 Architectural 
Model for definition.
3.1.33.	task identifier: The entity used to identify a task for a task management function. See the SCSI-3 
Architectural Model for definition.
3.2.   Symbols and Abbreviations
lsq 	- least significant quadlet
msq 	 -  most significant quadlet
isoch	 - Isochronous
async	 -asynchronous
CDS 	- command data structure
ACA	 - Auto Contingent Allegiance
4.0.   General
SBP cannot operate until the IEEE 1394 bus is initialized.  Following the bus initialization the transaction layer 
services of IEEE 1394 are used to transfer commands and data.
SBP requires the implementation of the general ROM format in each device as specified in IEEE 1212 for the 
configuration ROM.
Upon successful completion of initialization of the IEEE 1394 bus, each node will have a unique node 
identifier.  IEEE 1394 hardware provides means to detect the physical removal or addition of a node (i.e., not 
power on or off).  In either case, appropriate bus initialization occurs, and this may involve a given node 
obtaining new, unique offset, possibly different from the offset obtained during a prior initialization.
After IEEE 1394 bus initialization, the initiator reads the configuration ROM of each node looking for nodes 
implementing SBP.  The configuration ROM contains a data structure, which when parsed, describes the 
existence of one or more units, each of which may implement SBP or some other protocol.
The configuration ROM provides information to construct a worldwide unique 64-bit address for the node.   
This provides the means to maintain a system wide knowledge of  each device as a unique entity on the bus in 
the face of different node identifier values obtained from one bus initialization to the next.
The configuration ROM also provides the addresses of the login FIFO's for each of the supported types of 
operation (asynchronous and/or isochronous).
After the initiator has parsed the configuration ROM  and determined that the target supports SBP the Serial 
Bus Protocol (SBP) can now be initiated.  The first step is to perform  a login procedure.
A login procedure (see clause 14) can either be for isochronous or asynchronous data transfers.  A login 
procedure is performed prior to the transfer of a command data structure (CDS) to the target other than the 
login CDS.  SBP defines the format of all CDS's.
The CDS (see clause 8) is the construct that is used for the delivery of command and control information from 
the initiator to the target.  A CDS may exist in a list called a chain.  The initiator writes the first CDS in a chain 
to a command FIFO using the tap protocol (see clause 9).  The target fetches the second and subsequent 
CDS's in a chain using the fetch protocol (see clause 10).
The CDS contains information which the target uses to return status for that CDS.  The CDS also contains 
information which the target uses to return sense data to the initiator if an exception occurs.  
All exception handling (isochronous and asynchronous) and the asynchronous command task set management 
rules are defined in the SCSI-3 Architecture Model (SAM).
Target implementation determines the number of taps that can be accepted before a reject occurs.  SBP 
provides management facilities by which cooperating initiators and targets can eliminate the possibility of a tap 
being rejected by a target.  Clause 14.3 defines the tap slot allocation procedure.
Initiators that want to receive notification of asynchronous events can sign in with a target and thereby provide 
information by which the target can inform the initiator of the asynchronous event.  Clause 14.4 defines the 
sign in procedure.
4.1.   Conventions
Certain words and terms used in this standard have a specific meaning beyond the normal English meaning.  
These words and terms are defined either in the glossary or in the text where they first appear.  Lower case is 
used for words having the normal English meaning.
Fields containing only one bit are usually referred to as the "named" flag instead of the "named" field.
Data units follow the naming conventions used in IEEE 1394, byte (byte), four bytes (quadlet), eight bytes 
(octlet).  These data units also constitute a continuous stream of bits to which a bit numbering and binary 
weighting scheme are applied.  Within in a collection of continuous bits, the bit having the highest binary 
weighting is referenced as bit zero.  Remaining bits in the stream of bits are referenced in terms of 
displacement from bit zero.
Numbers that are not immediately followed by lower-case "b" or "h" are decimal values.
Numbers immediately followed by lower-case "b" (xxb) are binary values.
Numbers immediately followed by lower-case "h" (xxh) are hexadecimal values.
Table 1 illustrates the bit ordering used in SCSI and in 1394 and how they relate to each other.
Table 1 - Bit ordering in a byte
SCSI
7
6
5
4
3
2
1
0
1394
0
1
2
3
4
5
6
7

msb






lsb
Table 2 illustrates the byte ordering within a quadlet used in SCSI and in IEEE 1394 and the bit significance 
within the bytes.
Table 2 - Byte ordering within a quadlet
Note 1
most significant byte
 
 
least significant byte
Note 2
byte 0
byte 1
byte 2
byte 3
Note 3
msb          lsb
msb          lsb
msb          lsb
msb          lsb
Note 4
0              7
8             15
16            23
24            31
Note 5
7             0
7              0
7           0
7           0
Note 1:	This row depicts the location within the quadlet of the byte having the highest 
binary weighting (most significant) and the location of the byte having the lowest binary 
weighting (least significant). 
Note 2:	This row depicts the naming convention for bytes within a quadlet. 
Note 3:	This row depicts the location of the most significant bit and least significant bit 
within each byte comprising a quadlet. 
Note 4:	This row depicts the naming convention used by IEEE 1212/IEEE 1394 for the 
individual bits within a quadlet. 
Note 5:	This row depicts the naming convention used by SCSI for the individual bits within 
a byte.
  As there are four bytes in a quadlet this illustrates the application of this convention to each 
of the bytes.

5.0.   Model of serial bus protocol
This section describes a model of how the Serial Bus Protocol (SBP) operates on the IEEE 1394 High 
Performance Serial Bus.
The following description of SBP applys to both asynchronous and isochronous operation, as described in 
IEEE 1394 High Performance Serial Bus standard.  Elements that are common to these two modes of 
operation are the protocols for command and status delivery, with the key difference between the two modes 
of operation being in the transport of media data.  The differences are cited in the appropriate clauses with in 
this document.
5.1.   IEEE 1394 MEMORY MAP and ADDRESS SPACE
The Serial Bus follows the IEEE 1212 standard for 64-bit fixed addressing, where the upper 16 bits of each 
address represents the node_ID. This allows address space for up to 64K nodes. The Serial Bus divides the 
node_ID into two smaller fields: the higher order 10 bits specify a bus_ID and lower order bits specify a 
physical_ID.
5.1.1.   Configuration ROM
All IEEE 1394 nodes that implement SBP shall have a configuration ROM. The configuration ROM is read 
during bus initialization and may be read at anytime thereafter. (See clause 6.1) The IEEE 1394 standard 
defines the base address of this ROM and the IEEE 1212 standard defines the format of the information 
contained in this ROM.  Annex A contains an example of a configuration ROM which is compliant with IEEE 
1394, IEEE 1212 and SBP.  Other implementations are possible.
5.1.2.   Command FIFO
A key element of the logical model of SBP is the Command FIFO.  A Command FIFO is a write only data 
structure located at a fixed address within the target's address space and is used in support of a logical set of 
SBP functions (command, control, and sense information). In order for the Initiator to obtain the addresses of 
the Command FIFO's it must first perform a Login operation. (See Clause 11.1)  Processing the Login CDS 
returns the addresses of requested (asynchronous or isochronous) Command FIFO's. 
While the protocol requires multiple Command FIFO's, it is possible to build a conforming device that maps all 
FIFO's to a single address.  At the other end of the spectrum each login may result in a different address 
assigned to the normal, urgent, and ACA FIFO's.
5.2.   Command Data Structures (CDS)
Another element of SBP is a data structure called a command data structure (CDS) that may carry the SCSI 
CDB. SBP also defines a number of CDS's for various control and management functions, which do not carry 
CDB's. The CDS contains information, such as  that used to link a sequence of CDS's into a chain, initiator 
identifier, logical unit identifier, and pointers into initiator memory for various other operations. 
Initiators write CDS's to the address of a Command FIFO as part of the command delivery protocol. This 
operation is called a TAP. Targets may read CDS's from Initiator memory also as part of the command 
delivery protocol. This operation is call a FETCH.
The format of the SCSI CDS, contains space for a 16 byte SCSI CDB, and is defined in Clause 10.2.1. The 
SCSI CDS shall only be written to any one of the collection of asynchronous command FIFO's. For SCSI 
CDS's written to an asynchronous command FIFO, the carried CDB shall be entered into a task set. The rules 
governing CDB handling, for CDS's in a task set, are defined in SAM.
The format of the isochronous SCSI CDS, contains space for a 16 byte SCSI CDB, and is defined in Clause 
10.2.2. The key distinction of the isochronous SCSI CDS is that it shall only be written to any one of the 
collection of isochronous command FIFO's. For Isochronous SCSI CDS's written to an isochronous command 
FIFO, the carried CDB shall not be entered into a task set. The rules governing CDB handling, for CDB's 
carried in an isochronous SCSI CDS, are defined within this document (SBP).
5.2.1.   TAP slots
A TAP slot is a resource within a target. One or more taps may be associated with each Command FIFO.  The 
TAP slot is allocated to an initiator, if requested, during the login procedure.  However the initiator is not 
required to request an allocation of tap slots prior to writing a CDS.  During the login procedure, the target 
returns the number of slots allocated to the initiator in the new tap slot count field of the login data.  When the 
allocation is made the target removes that number of tap slots from the pool of tap slots. In normal usage the 
target does not enforce the tap slot allocation (i.e., restrict an initiator to use only those tap slots requested). 
Allocated tap slots will be reused by multiple taps coming from a given initiator.  In a cooperative multi-initiator 
environment the use of tap slot allocations can eliminate the rejection of a tap. There may also exist a pool of 
tap slots which have not been allocated.  These are available to be used by any initiator on a first come first 
served basis.  The use of a tap slot from the pool is for the duration of a CDS chain.  Once the CDS chain has 
completed then the tap slot returns to the pool of tap slots not allocated. In a cooperative multi-initiator 
environment a target shall never reject a tap.
5.2.2.   CDS chains
In certain applications, a high level logical work item results in many physical level I/O commands which 
originate over such a small interval of time that the multiple commands constitute a block of work to be done 
by the target device. It becomes a natural as well as efficient solution to process these commands by forming 
them into a CDS chain. Individual commands within a CDS chain do not need to have any particular logical 
relationship to one another. However, in many instances there is some relation among the commands as 
viewed by the initiator.
The CDS chain is a data structure which is created by the initiator and maintained within initiator memory 
space. A wide range of choices is given to the initiator as to the relationship between CDS's in a chain.  For 
example, the same chain may contain CDS's intended for different logical units supported by the given target, 
or the initiator may organize a chain so that it contains CDS's intended for one of the several logical units 
implemented at the target.  The same initiator may direct different chains to the same logical unit identifier.  
Every CDS within the same chain is directed to the same target.  Asynchronous and isochronous command 
chains are both options within SBP.  Initiators shall not mix asynchronous, isochronous, and task management 
CDS's within the same chain.  An asynchronous chain can support all of the normal SCSI-2, SCSI-3 type 
commands as well as certain SBP defined unit management functions.  Some CDS formats have restrictions 
about how they can exist in a chain.  Consult the CDS format definitions in this standard for details.
5.2.3.   CDS movement
In the movement of a CDS, there are two methods of moving a CDS from an initiator to a target. One method 
is as a result of unsolicited delivery (of a CDS) which uses the tap protocol. See 5.1.1. TAP Slots above. A 
TAP is a 64 byte IEEE 1394 write request transaction, originated by an initiator. The other method of moving a 
CDS is a FETCH, which is a read request transaction, originated by a target, for the purpose  of obtaining all or 
part of a CDS. 
There are three states defined in the movement of a CDS from an initiator to a target.  In the first state, the 
CDS exists only in initiator memory and the target has no knowledge of it.  In the second state, the CDS has 
been acquired by the target, via a tap or fetch, and a copy of the CDS exists in both the initiator and the target. 
The third state has multiple definitions depending on the content of the CDS.
A SCSI CDS, which carries a CDB, enters the third state when the command (SCSI CDB) contained in the 
CDS, is entered into a task set. Task management or other SBP control CDS's (CDS's which do not carry a 
CDB) enter the third state when the target schedules the time at which it processes the information carried by 
the CDS. Isochronous SCSI CDS's, which carries a CDB but is directed to an isoch command FIFO, enter the 
third state is when the target processes the information provided by the CDS. 
The delivery of a tap, or the fetch of a CDS, marks the transition from the first state to the second.  Once this 
transition has occurred the initiator is not allowed to modify any CDS within the chain with the exception of the 
abort task flag.
A target may fetch all or part of a CDS as many times as needed until the SBP status block is returned for that 
CDS.  A target may also discard all or part of a CDS after it is fetched except for the address of the CDS and 
the task attributes.  The task attribute is in effect at the time of the first acquisition of any part of the CDS.
5.2.4.   Task sets
The Task Set is a SCSI construct and its operation is governed by the SCSI Architecture Model. The Task Set 
applies to the mode of SBP operation in which application (media) data is to be transported by the IEEE 1394 
asynchronous transfer mechanism. For the mode of SBP operation in which application (media) data is to be 
transported by the IEEE 1394 isochronous transfer mechanism, there is no isochronous task set defined, even 
though some of the exception handling methods of the task set are utilized. In particular, while the Isochronous 
SCSI CDS employs a SCSI CDB to define media extents, and uses SCSI defined error conditions  for 
exception handling, the CDB is not entered into the SCSI Task Set.
For the SCSI CDS, the transition from the second state to the third state occurs when a target enters the 
command (SCSI CDB) contained in the CDS into a task set.  Entry into a task set is done prior to execution of 
the SCSI CDB. Acquisition of a CDS by the target is a different event than the entry of the command it 
contains into a task set.  In the event that multiple task sets exist a target shall enter the command into only 
one task set.
Note: The login and task management CDS's are not entered into a task set since they do not 
contain CDB's.
The target shall conform to the SCSI Architectural Model (SAM) as to the order in which commands, in the 
task set, are processed.
5.2.5.  Time stamp
Each CDS chain has a time stamp based on the order of arrival of the tap at the target.  Unless use is made of 
the SCE flag, each and every CDS within a chain has the same time stamp.  Additionally, chains are to have 
CDS's fetched from them in the order specified by the implied stamp.  A chain with earlier time stamp has 
CDS's fetched from it before CDS's are fetched from chains with a later time stamp.
If the SCE flag is set, then the present CDS marks the end of one sub-chain and the next CDS (within this 
chain) marks the start of a new sub-chain.  Setting the SCE flag, causes the time stamp to be advanced to the 
present time for all CDS's remaining within the chain.  The remaining CDS's are viewed as existing within a 
new chain, a sub-chain, and this sub-chain now has a time stamp later than the time stamp of all other chains 
known to the target.  If no other CDS has the SCE flag set, CDS's are fetched (in time sequence order) from 
all other chains before any CDS is fetched from the new sub-chain.
It is useful to consider an example of a limiting case for the setting of the SCE-flag in a set of CDS's.  In this 
case, the SCE-flag is set in every CDS.  The effect is that one CDS is fetched from each chain in a 'round 
robin' procedure based on the time stamp associated with each of the chains.  This case only affects the fetch 
policy; the order of completion is still governed by the SCSI-3 Architecture Model.
5.3.  Data transfers
The target transfers target data to or from the initiator in response to a CDS.  Target data is defined as any 
data which an initiator requests the target to transfer.  This includes data such as login in response data, 
device media data, scanner data, etc. The transfer of application data can use either asynchronous transfer 
mode or isochronous transfer mode.  All commands, status blocks, and sense data shall use asynchronous 
transfer mode.  Within each command CDS the initiator specifies the address for each data buffer to which the 
target will execute the block read or block write transaction.  The data transfer control field in a CDS provides 
control information regarding transfer rate, alignment, and packet size.  The data transfer rate field specifies 
the maximum speed to be used when transferring data.  The target shall use IEEE 1394 block read and block 
write transaction services when transferring data via the asynchronous transfer mode.
For certain application (media) data, the transfer means may be via the IEEE 1394 isochronous transfer mode. 
The isochronous data transfers make use of a simplified Link layer protocol supported by the LK_ISO.request 
and the LK_ISO.indication link layer services defined within the IEEE 1394 standard.
5.3.1.  Asynchronous transfers
Asynchronous data transfers provide for the movement of data without guarantee of bandwidth but with an 
acknowledgment protocol establishing correct receipt of all data transferred. Asynchronous data packets are 
defined within the IEEE 1394 document.
The rate of data transfer shall be as specified in the data transfer control field of the CDS associated with the 
CDB currently in execution.  Normal completion of the CDB occurs when the full amount of data specified by 
the CDB and associated CDS transfer length field, is transferred.  Such completion may require multiple 
asynchronous data transfer packets with the division into IEEE 1394 packets being the responsibility of the 
SBP application layer in the target.
5.3.2.  Isochronous transfers
Isochronous data transfers provide for the transfer of data with a fixed rate over time. Isochronous data 
packets are defined with the IEEE 1394 document. Isochronous data packets are not acknowledged and may 
be received by zero, one, or more than one node.
The manner of scheduling isochronous transfers is not given by SAM. The application based requirement is to 
transfer isochronous data in the exact order specified by the initiator in all cases.  SCSI CDB's are conveyed to 
the target in order to specify the area on target media which will receive data if the target is to be an 
isochronous listener, or the area on target media which will supply the data if the target is to be an isochronous 
talker. The target shall process the SCSI CDB's in the exact order as specified by the initiator. It is particularly 
convenient for both the initiator and the target if the initiator forms the SCSI CDS's into one or more CDS 
chains. In this manner the target can control the point in time at which a given CDS is fetched and 
subsequently processed.
The isochronous SCSI CDS's describe a time-ordered set of data that the target transmits or receives using 
the IEEE 1394 isochronous data transfer mode. The rate at which the isochronous data stream is to be 
transferred to the IEEE 1394 bus is defined by the L, I, N, and D parameters (See Annex C) provided by the 
isochronous login CDS. Start, Stop, and Pause information for an isochronous stream is specified in a Isoch 
Control CDS and effectively control the scheduling of transmission of isochronous data packets.
Completion of a given isochronous SCSI CDS occurs when all the data specified by the command have been 
transferred. Multiple isochronous packets are required to transfer the data associated with one SCSI CDB. 
Status upon completion of a isochronous SCSI CDS is reported in the usual manner defined by SBP. Special 
error logging conventions are defined in clause 7.5 as applied to isochronous data transfer.
5.4.  Auto sense
SBP provides a means to enable sense data to be returned without the initiator sending a REQUEST SENSE 
command.  Sense data is  sent to the address specified by the command CDS sense buffer address field. The 
initiator may indicate that it does not want the target to automatically send the sense data by setting the auto 
sense length field to zero.  When the target returns auto sense data the sense data sent (SDS) flag shall be  
set to one. 
The sense data format in SBP is compatible with the sense data format used in the Fibre Channel Protocol.
5.5.  Asynchronous event notification
The initiator can enable the notification of asynchronous events using the login procedure or the sign-in 
procedure.  In either case the procedure establishes an AE buffer within initiator memory to which the AE 
sense data is sent.  Following notification of an asynchronous event the initiator is required to implement a 
sign-in procedure to be notified of a subsequent AE.  See SCSI-3 Architectural Model document for further 
information.
5.6.  Exception handling
SBP conforms to all of the exception handling defined within the SCSI-3 Architectural Model (SAM) document.  
SBP implements all of the required SCSI-3 Architectural Model (SAM) services for exception handling.  Refer 
to the SCSI-3 Architectural Model (SAM) document for the model that shall be used in SBP and to clause 6, of 
this document, for SBP specific implementation. 
6.0.  SCSI-3 Architecture model services
This clause defines the services which are implemented in SBP. These services are defined in detail in the 
SCSI-3 Architectural Model (SAM) document.  Services consist of the command execution service, data 
delivery services, and task management services.
6.1.   Command execution services
All CDS's are transmitted from the initiator to the target, either by a tap or a fetch. The CDS is the means by 
which the initiator transfers SCSI command (CDB's) to the target.
Exception conditions and error processing associated with command execution are defined in clause 6.4.
6.1.1.   Tap protocol
The tap protocol is the means by which an initiator sends the first 64 bytes of a CDS in a chain to the target.   
The destination address shall be the address of one of the target's command FIFO's.  The target shall  acquire 
subsequent CDS's in the chain, if any, using the fetch protocol defined below. A target must always have the 
ability to receive a CDS and examine its contents even if all tap slots are allocated and in use. In this manner, 
a target which has committed its entire set of normal priority Tap slots can still accommodate SAM task  
management services such as Clear Task Set  or Abort Task.
If the target does not accept a tap, the target shall return a status block with a CDS status of TAP SLOT NOT 
AVAILABLE, (Table 9 code 12h ).  The target shall not execute the tap  and may discard it once CDS status 
has been sent. In a cooperative multi-initiator environment, where no initiator exceeds its tap slot allocation, a 
target shall never reject a tap.
6.1.2.   Fetch protocol
The fetch protocol is the means by which the target acquires subsequent CDS's, within a chain, from the 
initiator.  A fetch is an IEEE 1394 transaction data request of type READ with a data length of 64.   The 
address, within the initiator, of the CDS to be fetched is identified in the previously acquired CDS.  The target 
is allowed to fetch any CDS within a chain until it returns a status block for the CDS. After the target returns a 
status block for a CDS, the target shall not fetch any portion of that CDS, nor shall it access any data structure 
referenced by that CDS including the sense data buffer.  
6.2.   Data transfer services
The data transfer protocol is the means by which data is transferred to or from the target in response to a CDS.  
Data is defined as any data which a CDS specifies. This includes data such as login in response data, disk 
drive media data, scanner data, etc. Data may be moved using two transfer modes, asynchronous and 
isochronous. 6.2.1.  Data transfer from target to initiator
The target shall transfer data to the initiator's address space as specified within the CDS. The address 
specified within the CDS may or may not be associated with the initiator that issued the CDS. The bus speed, 
transfer length, and alignment of each data request shall comply with the settings in the data transfer control 
field of the CDS. 
Each request shall be to an address within the range of addresses specified by the data buffer address field 
and the transfer length field in the CDS.  No transaction shall extend beyond or start before the buffer 
indicated by the data buffer address and transfer length CDS fields.
6.2.2.   Data transfer from initiator to target
The initiator shall transfer data to the target's address space as specified within the CDS. The bus speed, 
transfer length, and alignment of each data request shall comply with the settings in the data transfer control 
field of the CDS.
Each request shall be to an address within the range of addresses specified by the data buffer address field 
and the transfer length field in the CDS.  No transaction shall extend beyond or start before the buffer 
indicated by the data buffer address and transfer length CDS fields.
6.3.   Task management services
Task management services are issued by the initiator to control the flow and execution of one or more tasks 
within the target. These services conform to the task management functions defined in the SCSI-3 
Architectural Model (SAM) document.
6.3.1.   Abort task
This section describes the protocol by which SBP accomplishes the SAM ABORT TASK, task management 
function.
To perform an abort task function an initiator, first, sets the Abort-flag in the CDS located in the initiator 
memory.  The initiator then sends a task management CDS with abort task flag set (byte 22 bit 7=1), to the 
target.  The task to be aborted is identified within the tag value field of the task management CDS. 
The service response to abort task is always function complete.  That is, an SBP status block is returned with a 
CDS status of SCSI status invalid set and an SBP status of no status to report.
The target shall indicate that the requested task has been aborted by returning an SBP status block with CDS 
status of SCSI status invalid set and an SBP status of no status to report. 
Note that the target must always fetch the CDS in order to obtain the address of the next CDS in the chain
If the task completed before the abort task was executed by the target SBP status block shall have been 
returned but the SCSI status invalid bit will not be set.
6.3.2.   Abort task set
This section describes the protocol by which SBP accomplishes the SAM ABORT TASK SET, task 
management function.
To perform an abort task set function an initiator sends a task management CDS with the abort task set flag 
set (byte 22 bit 6= 1). 
For the specified task set the target response shall be :
1) stop issuing transaction data requests for the affected task set;
2) wait for any pending transaction data responses to complete;
3) return SBP status block with SCSI status invalid set in the CDS status byte, and SBP status byte 
    set to no status to report.
The target shall not transfer SBP status, data, or sense information for any pending CDS acquired prior to the 
time the abort task set function was received.
6.3.3.   Clear task set
This section describes the protocol by which SBP accomplishes the SAM CLEAR TASK SET task 
management function.
To perform a clear task set function an initiator sends a task management CDS with the clear task set flag set 
(byte 22 bit 5= 1).
For the specified task set the target response shall be :
1) stop issuing transaction data requests for the affected task set;
2) wait for any pending transaction data responses to complete;
3) return SBP status block with SCSI status invalid set in the CDS status byte, and SBP status byte
    set to no status to report.;
4) establish a unit attention condition for all task identifiers;
The target shall not transfer SBP status, data, or sense information for any pending CDS acquired prior to the 
time the clear task set function was received.
6.3.4.   Clear auto contingent allegiance
This section describes the protocol by which SBP accomplishes the SAM CLEAR ACA, task management 
function.
To perform a clear task set function an initiator sends a task management CDS with the clear ACA flag set 
(byte 22 bit 1= 0).    As a  restriction, while the ACA condition continues to be declared by a target:  (a) CDS 
fetch operations, by the target, shall only take place in relationship to an ACA tap message received at the 
ACA FIFO, (b) CDS execution shall only take place in relation to CDS's having the ACA queue type. 
Once the ACA condition has been cleared an SBP status block is returned with a SCSI status of command 
terminated, and an SBP status of no status to report. For further details of the ACA conditions refer to the 
SCSI-3 Architectural Model (SAM) document.
6.3.5.   Target reset
This section describes the protocol by which SBP accomplishes the SAM TARGET RESET, task management 
function.
To perform a target reset function an initiator send a task management CDS with the target reset flag set (byte 
22 bit 2= 1). When the target has completed the reset, an SBP status block is returned with a SCSI status of 
good, and an SBP status of no status to report. An SBP target shall conform to the specified hard reset defined 
in the SCSI-3 Architectural Model (SAM) document.
6.3.6.   Terminate task
This section describes the protocol by which SBP accomplishes the SAM TERMINATE TASK, task 
management function.
Support for this function is a logical unit option. To perform a terminate task function an initiator sends a task 
management CDS with the terminate task flag set (byte 22 bit 4 = 1). In conformity to the SAM requirements 
established for this task management function, the logical unit supporting this option shall, with the following 
SAM specified exceptions, complete the specified task and return SCSI status of  COMMAND TERMINATED 
and an SBP status of no status to report. The sense key, additional sense code, and qualifier  shall be set as 
specified by SAM.
If the work performed by the terminated task involves the transfer of data, the supporting logical unit shall 
proceed as specified by the SAM document with regard to setting  the valid bit in the sense data  and the 
information field.
If an error is detected for the specified task, the supporting logical unit shall ignore the Terminate Task request 
and shall return a service response of  Function complete.
If the target does not support the Terminate Task function or is unable to stop the task, the target shall return a 
service response of Function Complete.
6.4.   Exception and error processing
Exception conditions and errors associated with the transfer of commands and/or data shall be processed as 
specified in the following clauses. Distinctions are made and possibly different actions are taken based upon 
whether errors are detected during the asynchronous or the isochronous transfer modes. The following set of 
general rules govern exception and error processing with SBP.
(a) For transaction which do have idempotence property there shall be no retries. 
(b) SBP specifies target retry behavior for transactions which do not have the idempotence property.
(c) Isochronous transfers involve only application data and It is left to application and/or implementation 
decision as to the exception handling processing.
6.4.1.   Tap transfer exceptions
For specification of exception processing refer to clause 7.2.
6.4.2.   Fetch transfer exceptions
For specification of exception processing refer to clause 7.3.
6.4.3.   Asynchronous data transfer exceptions
For specification of exception processing refer to clause 7.4.
6.4.4.   Isochronous data transfer exceptions
For specification of exception processing refer to clause 7.5.
7.0.   SBP Transaction management
In the IEEE 1394 physical interface environment, communications with the SBP is accomplished via the 
services and facilities provided by the IEEE 1394 Transaction layer component. The transaction layer provides 
a complete request-response protocol to communicate with the application layer. Within this structure SBP is 
defined as the application layer.
7.1   Transaction services
The SBP (application) layer uses the following Transaction layer services:
Transaction Data Request (TR_DATA.request)
Transaction Data Confirmation (TR_DATA.confirmation)
Transaction Data Indication (TR_DATA.indication)
Transaction Data Response (TR_DATA.response)
A transaction is started by an application layer (requester) issuing a TR_DATA.request to its local transaction 
layer. The transaction layer sends a request packet via the IEEE 1394 bus. When the receiving Transaction 
Layer receives the request packet, a TR_DATA.indication is issued to the application layer (responder). The 
responder application layer reacts in an appropriate manner to the TR_DATA.indication, and issues a 
TR_DATA.response to the responder transaction layer. The transaction layer sends a response packet via the 
IEEE 1394 bus. When the receiving Transaction Layer receives the response packet, a 
TR_DATA.confirmation is issued to the application layer (requester), thus completing the transaction.
The transaction layer does not provide any services to the application layer for Isochronous transfers. These 
services are provided by the IEEE 1394 Link Layer component.  
7.1.1.   Transaction data request (TR_DATA.request)
The SBP application layer issues a TR_DATA.request to its Transaction layer to start a transaction. The 
following transaction types are supported by the IEEE 1394 bus.
WRITE    Used by SBP
READ      Used by SBP
BROADCAST WRITE   Not used by any SBP protocol
LOCK   Not used by any SBP protocol
7.1.2.   Transaction data confirmation (TR_DATA.confirmation)
The SBP application layer (requester) receives a TR_DATA.conformation from its Transaction Layer in order 
to confirm the completion of a transaction. The following status values are supported:
COMPLETE
TIME-OUT
ACKNOWLEDGE MISSING
RETRY LIMIT
DATA ERROR
Exception condition processing by the SBP application layer is discussed in clauses 7.2 through 7.5. This 
processing is dependent upon the specific SBP protocol in which the confirmation is received.
7.1.3.   Transaction data indication (TR_DATA.indication)
The SBP application layer receives a TR_DATA.indication from its Transaction Layer to indicate the arrival of 
a request packet. The following transaction types are supported by the IEEE 1394 bus.
WRITE    Used by SBP
READ      Used by SBP
BROADCAST WRITE   Not used by any SBP protocol
LOCK   Not used by any SBP protocol
7.1.4.   Transaction data response (TR_DATA.response)
The SBP application layer issues a TR_DATA.response to its Transaction Layer to cause a response 
packet to be transferred to the requester. The following transaction types are supported by the IEEE 
1394 bus.
WRITE   Used by SBP 
READ     Used by SBP 
BROADCAST WRITE   Not used by any SBP protocol
LOCK   Not used by any SBP protocol
The disposition of the request is contained within the response code carried by the response packet.
7.2.   Tap transaction
A tap transaction is TR_DATA.request of type WRITE, with a data length of 64, issued by the initiator 
application layer. The requester is the initiator, and the responder is the target. The destination address shall 
be the address of one of the target's FIFO's. The SBP application layer at the requester takes the following 
exception condition processing upon receipt of the confirmation associated with the original transaction 
request.
COMPLETE - 
TARGET CASE:  Not Applicable
INITIATOR CASE:  Successful transaction, no exception condition processing needed
TIME-OUT - 
TARGET CASE:  Not Applicable
INITIATOR CASE:  Shall not retry.  The initiator may abort task, reset target, or reset bus. The choice 
of action is initiator implementation dependent.
ACKNOWLEDGE MISSING -
TARGET CASE:  Not Applicable
INITIATOR CASE: Shall not retry.  The initiator may abort task, reset target, or reset bus. The choice 
of action is initiator implementation dependent.
RETRY LIMIT - 
TARGET CASE:  Not Applicable
INITIATOR CASE:  May retry again.  flag CDS aborted, or reset the bus.  The choice of action is 
initiator implementation dependent.
DATA ERROR. (no distinction is made between under-runs, overruns, or CRC type errors)
Note: A data error indicates a transient condition affecting target/initiator communications. The 
target shall not use this response to reject a tap.
TARGET CASE:  Not Applicable
INITIATOR CASE:  May retry again. The choice of action is initiator implementation dependent. 
7.3.   Fetch transaction
A fetch transaction is a TR_DATA.request of type READ, with a data length of 64, issued by the target 
application layer.  The source address shall be the address of the CDS within initiator memory space. The 
requester shall be a target, and the responder shall be an initiator.
The SBP application layer at the requester takes the following exception condition action upon receipt of the 
given confirmation associated with the original transaction request. The exception condition processing by the 
initiator applies only to the response subaction needed to satisfy the read request issued by the target. 
COMPLETE - 
TARGET CASE:  Successful transaction, no exception condition processing needed
INITIATOR CASE:  Successful completion of read response subaction, no exception condition 
processing needed.
TIME-OUT - 
TARGET CASE:  Retry request again,  continue to retry until successful or until directed otherwise by 
the initiator.
INITIATOR CASE:   Not Applicable  A time out can not occur on a response subaction.
ACKNOWLEDGE MISSING -
TARGET CASE:  Retry request again, continue to retry until successful or until directed otherwise by 
the initiator.
INITIATOR CASE: Shall not retry.
RETRY LIMIT
TARGET CASE: Retry request again, continue to retry until successful or until directed otherwise by 
the initiator.
INITIATOR CASE:  No further retry, retry limit is initiator implementation decision.
DATA ERROR. (no distinction is made between under-runs, overruns, or CRC type errors)
TARGET CASE: Retry request again, continue to retry until successful or until directed by the initiator 
to do otherwise.
INITIATOR CASE: Shall not retry.
7.4.   Asynchronous data transfer 
Asynchronous data transfer transactions are started by the SBP application layer at the target issuing 
TR_DATA.request. Because of the need to perform differing exception condition processing depending on the 
category of data to be transferred, the following different categories are discussed separately below:
application data, sense data, AE report data
login response data,
status data
7.4.1.   Application data transfer target to/from initiator
The target, upon request, shall transfer data to/from the initiator's address space by generating one or more 
transaction data requests. If data is to move from the target to the initiator, then the target SBP layer issues a 
TR_DATA.request of type WRITE. If data is to move from the initiator to the target, the target issues a 
TR_DATA.request of type READ. The data amount shall be consistent both with the transfer length specified 
within the data transfer control field of the associated SCSI CDS and the maximum data packet length for the 
IEEE 1394 bus speed used. The SBP application layer at the target takes the following exception condition 
processing upon receipt of the given confirmation associated with the original transaction request. The 
exception condition processing by the initiator applies only to the response subaction needed to satisfy the 
read request issued by the target. 
COMPLETE - 
TARGET CASE: Successful transaction, no exception condition processing needed.
INITIATOR CASE: Successful transaction. Successful completion of read response subaction, no 
exception condition processing needed.
TIME-OUT - 
TARGET CASE:  Retry request again,  continue to retry until successful or until directed otherwise by 
the initiator.
INITIATOR CASE:   Not Applicable  A time out can not occur on a response subaction.
ACKNOWLEDGE MISSING -
TARGET CASE:  Retry request again, continue to retry until successful or until directed otherwise by 
the initiator.
INITIATOR CASE: Shall not retry.
RETRY LIMIT
TARGET CASE: Retry request again, continue to retry until successful or until directed otherwise by 
the initiator.
INITIATOR CASE:  No further retry, retry limit is initiator implementation decision.
DATA ERROR. (no distinction is made between under-runs, overruns, or CRC type errors)
TARGET CASE: Retry request again, continue to retry until successful or until directed by the initiator 
to do otherwise.
INITIATOR CASE: Shall not retry.
7.4.2   Login data transfer from target to initiator
The target shall transfer login data using an TR_DATA.request of type WRITE. The SBP application layer at 
the target shall take the following exception condition processing upon reception of the given confirmation. 
There shall be at most one successful transfer of any given login data block.
COMPLETE - 
TARGET CASE: Successful transaction, no exception condition processing needed.
INITIATOR CASE: NA
TIME-OUT - 
TARGET CASE:  Shall not retry. Target shall abort the login CDS and shall return status block with 
SBP status code login error.
INITIATOR CASE:  NA
ACKNOWLEDGE MISSING -
TARGET CASE:  Shall not retry. Target shall abort the login CDS and shall return status block with 
SBP status code login error.
INITIATOR CASE: NA
RETRY LIMIT
TARGET CASE: Shall not retry. Target shall abort the login CDS and shall return status block with 
SBP status code login error.
INITIATOR CASE:  NA
DATA ERROR. (no distinction is made between under-runs, overruns, or CRC type errors)
TARGET CASE: Shall not retry. Target shall abort the login CDS and shall return status block with 
SBP status code login error.
INITIATOR CASE: NA
7.4.3.   Status data transfer from target to initiator
The target shall transfer a status block using an TR_DATA.request of type WRITE with a length of 16. The 
SBP application layer at the target shall take the following exception condition processing upon reception of 
the given confirmation. There shall be at most one successful transfer of any given status block.
COMPLETE - 
TARGET CASE: Successful transaction, no exception condition processing needed.
INITIATOR CASE: NA
TIME-OUT - 
TARGET CASE:  Shall not retry. No further processing of CDS by the target.
INITIATOR CASE:  NA
ACKNOWLEDGE MISSING -
TARGET CASE:  Shall not retry. No further processing of CDS by the target.
INITIATOR CASE: NA
RETRY LIMIT
TARGET CASE: Shall not retry. No further processing of CDS by the target.
INITIATOR CASE:  NA
DATA ERROR. (no distinction is made between under-runs, overruns, or CRC type errors)
TARGET CASE: Shall not retry. No further processing of CDS by the target.
INITIATOR CASE: NA
7.5.   Isochronous data transfers
Isochronous data transfers are accomplished via the services and facilities provided by the IEEE 1394 Link 
layer component. The Link layer provides a simplified protocol to support isochronous data transfer. Within this 
structure SBP is defined as the application layer.
During the Isochronous data transfer portion of a cycle, no asynchronous transactions are transferred to/from 
the application layer. The number of bytes to be transferred in an isochronous data block shall not exceed an 
absolute maximum value based on the data rate used to transmit the block.   Refer to Annex C for the method 
of allocating isochronous bandwidth. 
7.5.1.   Link layer services
Link Layer services,  to/from the application layer, consist of the following:
Link Isochronous Control request (LK_ISO_CONTROL.request)
Link Cycle Start Indication (LK_CYCLE.indication) (hardware detected)
Link Isochronous indication (LK_ISO.indication)
Link Isochronous request (LK_ISO.request)
The SBP application layer queues the data to be transferred in the isochronous packet. When a Isochronous 
Control CDS is decoded, and data is available, an Isochronous transfer will begin as indicated in the stream 
event field of the CDS. When the Link Layer receives the Isochronous data block a LK_ISO.indication is sent 
to the application indicating receipt of the packet. The target or application layer does not respond to the 
LK_CYCLE.indication.
Multiple channels are possible within the application layer. The number and identification of the available 
channels is communicated to the Link Layer via the LK_ISO_CONTROL.request. When the Link Layer 
receives an Isochronous data block (from the physical interface) with one of the channel numbers identified by 
the application layer, a 
LK_ISO.indication is generated to begin the transfer of the data block to the application layer.
7.5.2.   Isochronous status reporting
This section describes target status reporting mechanisms for isochronous SCSI read and isochronous SCSI 
write commands. The target reports status for isochronous SCSI read and isochronous SCSI write commands 
in the following situations:
Command Completion
Missed isochronous cycle of data - intermediate status reporting
The target always reports status on completion of an isochronous SCSI read or an isochronous SCSI write 
command.  The protocol for doing this are the same as those for status reporting on completion of non-
isochronous SCSI read and SCSI write commands.
While executing an isochronous SCSI read command (target sources isochronous data), if the target misses a 
cycle of data due to an internal error or transient condition, the target invokes the isochronous status reporting 
mechanism defined below.  This mechanism is called intermediate isochronous status reporting.
While executing an isochronous SCSI write command (target sinks isochronous data), if the target misses an 
isochronous cycle of data, either because of missing data or due to an internal error or transient condition, the 
target invokes the isochronous status reporting mechanism defined below.  This mechanism is called 
intermediate isochronous status reporting.
There are three modes for intermediate isochronous status reporting.  The Isochronous Login command 
declares the status reporting mode to be used for a given stream.  The mode remains in effect for the entire 
life of the stream.  The three modes differ in the way that the target handles error conditions which occur 
during isochronous data transfer.  The three modes are:
Ignore and Continue - Target ignores all errors and continues isochronous data transfer
Report and Continue - Target logs errors as they occur and continues isochronous data transfer
Report and Stop - Target reports the first error that occurs and stops isochronous data transfer
7.5.3.   Ignore and continue
The target generates no status during isochronous SCSI read or isochronous SCSI write command execution.  
Upon encountering any error while reading or writing isochronous data, the target ignores the error and 
continues.
There is no status block associated with this mode of operation.
7.5.4.   Report and continue
If an error occurs during isochronous SCSI read or isochronous SCSI write command execution, the target 
generates an entry in an error log.  The address of the error log is contained in the CDS sense buffer address 
field of the isochronous SCSI read and isochronous SCSI write CDS's.
If the target generates any entries in the error log during execution of an isochronous SCSI read or 
isochronous SCSI write command, the target shall set the Sense Data Sent bit in the status block for that 
command.
If the target completely fills the allocated sense buffer, the target stops writing error log entries, but continues 
executing the command to completion. Upon completing the command, the target reports a status code in the 
status block indicating that the sense buffer is filled with error log entries and some entries were discarded due 
to overflow.
Each entry in the error log reports an event from the following list:
a)  Start of gap in the isochronous stream
b)  End of gap in the isochronous stream
A gap is defined as one or more consecutive isochronous cycles during which no isochronous data packet was 
transmitted or received on a given channel number.  The start of a gap is signified by one isochronous cycle 
during which an isochronous data packet for a given isochronous channel is not generated (due to a talker 
problem) or is not received (due to a listener problem, an isochronous header or data field CRC error, or 
missing packet).  The end of a gap is signified by the first isochronous cycle following the start of a gap in 
which a valid isochronous data packet is transmitted or received for a given channel number.  Note that a 
stream gap may appear at one device and not another.
As an example, if an isochronous stream is interrupted for multiple consecutive isochronous cycles and then 
resumed, the target will log 2 entries to the error log regardless of the duration of the stream gap:  One error 
log entry to report the start of the stream gap, and another error log entry to report the end of the stream gap.
Each entry in the error log is 2 quadlets long.  The format of each entry in the error log is defined in table C-2.
Table 3 - Error log entry
Byte
Function
0 to 3
Seconds high count
reserved
4 to 7
Seconds count/cycle count
reserved
status
The Seconds High Count is a 25-bit number which contains the value in the seconds_hi_count field of the 
Bus_Time CSR register on the cycle on which the error occurred.
The Seconds count/cycle count is a 20-bit field which contains the value in the seconds count and cycle count 
fields of the isochronous cycle start packet on which the error occurred.
The status identifies the event that occurred on the reported isochronous cycle number according to table 4.
Table 4 - Isochronous status codes
Status Code
isochronous cycle number field contains the cycle number of:
0
cycle number of first valid cycle of data following the stream gap
1
Start of gap due to an unidentified error condition
2
start of gap due to target unable to source/sink isochronous data
3
start of gap due to missing isochronous data packet (target is listener)
4
start of gap due to data field CRC error (target is listener)
The error log contains one entry for each start of gap detected and one entry for each end of gap detected 
(i.e., two error log entries per stream gap).  In the case where the target is the talker, the target reports errors 
to the error log if it is unable to generate isochronous data packets for whatever reason.  If the target is a 
listener, the target reports errors to the error log if it is unable to receive a packet, due to an internal error, a 
missing packet, or a data or header CRC error.
7.5.5.   Report and stop
In this operational mode, upon encountering an error, the target generates an entry in the error log and 
immediately stops execution of the current command.  The target returns a status block for the command 
indicating the error condition.

8.0.   Target memory
The target memory space contains configuration ROM and CSR's required by IEEE 1394.   Also in target 
memory  as specified by the Serial Bus Protocol are two sets of FIFO's, one set for asynchronous operations 
and one set for each channel used for isochronous operations.   Figure 3 is a illustration of a device with a 
single task set.  It serves as a conceptual framework and is not intended to imply an implementation.
 
Figure 3 - Block diagram of Serial SCSI Device
8.1.   Configuration ROM
All IEEE 1394 nodes that implement SBP shall have a configuration ROM.  The IEEE 1394 standard defines 
the base address of this ROM and the IEEE 1212 standard defines the format of the information contained in 
this ROM.  Annex A contains an example of a configuration ROM which is compliant with IEEE 1394, IEEE 
1212 and SBP.  Other implementations are possible.
The configuration ROM is read during bus initialization and may be read at anytime thereafter.
Configuration ROM in the target contains the address in target memory space of the login FIFO.
An SBP device is required to provide a data structure for each unit directory and unit dependent directory 
supported.  The data structures are shown in tables 5 and 6.
Table 5 - Unit Directory
Quadlet
Description
1
Directory length
Directory CRC
2
00b
 Key (13h)
Unit software version
3
00b
Key (12h)
Unit specifier id
4 - n
xxb
Key (14h)
Unit dependent directory offset
The unit directory contains a unit software version, a unit specifier id, and pointers to one or more unit 
dependent directories.
The directory length field contains the total number of quadlets in this directory entry minus one.  For example, 
a value of one in the directory length field indicates that the unit directory is comprised of two quadlets.
The directory CRC field contains the CRC of this directory.  The CRC is calculated beginning with the next 
quadlet and continuing for directory length quadlets.
A six-bit key field value of 13h indicates that the low order 24-bits of this quadlet contain the unit software 
version for this node.
The unit software version field contains the version of the software of this node.
A six-bit key field value of 12h indicates that the low-order 24-bits of this quadlet contain the unit specifier ID.
The unit specifier ID field contains the identification number of the entity defining the architectural interface of 
this unit.  A value of C2F4h indicates an SBP compliant device.
A six-bit key field value of 14h indicates that the low order 24-bits of this quadlet contain the unit dependent 
directory offset. 
The unit dependent directory offset field contains the offset from this entry, in quadlets, of the unit dependent 
directory.
Table 6 - Unit Dependent Directory
Quadlet
Description
1
Directory length
Directory CRC
2
xxb
 Key (21h)
Offset of asynchronous login FIFO
3
xxb
 Key (22h)
Offset of isochronous login FIFO
The unit dependent directory contains the offsets of the Asynchronous login FIFO and isochronous login FIFO.  
At a minimum the unit dependent directory contains at least one login FIFO offset and may contain multiple 
offsets for asynchronous or isochronous.
The unit dependent directory length field contains the number of quadlets in this directory entry.
The directory CRC field contains the CRC of the data in this directory calculated beginning with the next 
quadlet and continuing for unit dependent directory length quadlet's.
A six-bit key field value of 21h indicates that the low order 24-bits of this quadlet contain the offset of the 
asynchronous login FIFO.
The offset of asynchronous login FIFO field contains the offset, in quadlets, from the base of CSR space to the 
asynchronous login FIFO.
A six-bit key field value of 22h indicates that the low order 24-bits of this quadlet contain the offset of the 
isochronous login FIFO.
The offset of isochronous login FIFO field contains the offset, in quadlets, from the base of CSR space to the 
isochronous login command FIFO.
Note: The asynchronous login FIFO and the isochronous login FIFO may be at the same 
address or may implemented at different addresses from each other.
8.2.   Asynchronous FIFO's
This section describes the target FIFO's used for initiating and controlling an asynchronous task set.
The target supporting IEEE 1394 asynchronous data transfer mode shall implement all FIFO's described in this 
clause.
8.2.1.   Asynchronous login FIFO
The asynchronous login FIFO shall have its offset specified in the unit dependent directory if asynchronous 
data transfers are supported.  This FIFO is used for the asynchronous login procedure (see 14.4.1).  The FIFO 
is a write only address that accept a 64-byte tap.
8.2.2.   Asynchronous normal FIFO
The asynchronous normal FIFO is used for receiving taps that contain an SCSI CDS defining a command to 
be executed.  The address is provided as part of the login data during the login procedure.
The target may reject a tap sent to the asynchronous normal FIFO if it is unable to accept the CDS.  The 
initiator should retry the tap until the target has resources available to accept the CDS. In a cooperative multi-
initiator environment, where no initiator exceeds its tap slot allocation, a target shall never reject a tap
The number of asynchronous normal FIFO's available is implementation dependent, but shall be at least one 
per asynchronous task set.
8.2.3.   Asynchronous urgent FIFO
The asynchronous urgent FIFO is used for receiving taps that contain an SCSI CDS that defines a command 
to be fetched and entered into the task set on a priority basis.  The address is provided as part of the login data 
during the login procedure.
Note - The order of completion of commands is determined by the rules governing task sets in 
the SCSI-3 Architecture Model.
Any of the taps which may be sent to the normal FIFO may also be sent to the urgent FIFO.  The difference is 
in the priority of fetching the associated CDS's.
The number of asynchronous urgent FIFO's shall be one per asynchronous task set.
8.2.4.   Asynchronous ACA FIFO
The asynchronous ACA FIFO is used for receiving taps that contain a tap type of ACA and an SCSI CDS with 
an ACA task attribute for the purposes of recovering from an exception condition associated with 
asynchronous operation.  The address is provided as part of the login data during the login procedure.
If a CDS is received that does not have a tap type of ACA and an ACA task attribute then the target shall not 
execute the CDS and return a status of ILLEGAL REQUEST.  Once an ACA condition is established, and for 
the duration of the time the ACA condition exists, the target may only fetch CDS's directed to the 
asynchronous ACA FIFO.
No restriction shall exist with regard to fetching CDS's directed to an isochronous FIFO based upon existence 
of an asynchronous ACA.
The number of asynchronous ACA FIFO's shall be one per asynchronous task set.
8.3.   Isochronous FIFO's
This section describes the target FIFO's used for initiating and controlling an isochronous stream.  There shall 
be a one to one correlation between the isochronous task set and a stream identifier, i.e., each stream 
identifier has a task set.
A target supporting the IEEE 1394 isochronous data transfer shall implement all FIFO's described in this 
clause.
8.3.1.   Isochronous login FIFO
The isochronous login FIFO shall have its offset specified in the unit dependent directory if isochronous data 
transfers are supported.  This FIFO is used for the isochronous login procedure (see 14.4.2).  The FIFO is a 
write only address that accept a 64-byte tap.
8.3.2.   Isochronous normal FIFO
The isochronous normal FIFO is used for receiving taps that contain an SCSI command descriptor block 
defining a command to be executed.  The address is provided as part of the login data during the login 
procedure.
The target may reject a tap sent to the isochronous normal FIFO if it is unable to accept the CDS.  The initiator 
is expected to retry the tap until the target has resources available to accept the CDS. 
The number of isochronous normal FIFO's shall be one per stream identifier.
8.3.3.   Isochronous urgent FIFO
The isochronous urgent FIFO is used for receiving taps that contain an SCSI command descriptor block that 
defines a command to be executed on a priority basis.  The address is provided as part of the login data during 
the login procedure.
Any of the taps which may be sent to the normal FIFO may also be sent to the urgent FIFO.  The difference is 
in the priority of fetching the associated CDS's.
The number of isochronous urgent FIFO's shall be one per stream identifier.
8.3.4.   Isochronous ACA FIFO
The isochronous ACA FIFO is used for receiving taps that contain a tap type of ACA and an SCSI command 
descriptor block with an ACA task attribute for the purposes of recovering from an exception condition 
associated with the isochronous operation.  The address is provided as part of the login data during the login 
procedure.
If a CDS is received that does not have a tap type of ACA and an ACA task attribute then the target shall not 
execute the CDS and return a status of ILLEGAL REQUEST.  Once an ACA condition is established, and for 
the duration of the time the ACA condition exists, the target may only fetch CDS's directed to the isochronous 
ACA FIFO.
No restriction shall exist with regard to fetching CDS's directed to an asynchronous FIFO based upon 
existence based on the existence of an isochronous ACA.
The number of isochronous ACA FIFO's shall be one per stream identifier.

9.0.   Initiator memory
The initiator memory space contains the CDS's, status FIFO, sense data buffers, the asynchronous event 
buffers and the buffers associated with transfer of data.  Initiator memory also contains at least the general 
configuration ROM as well as various IEEE 1212 and IEEE 1394 specified CSR's. 
The target knows the location of the first CDS in a chain as a result of acquiring the CDS through a tap.  The 
location of subsequent CDS's in the chain are found from the address of the next CDS field.
The address of the status FIFO and sense data buffers are stated within the CDS to which they apply.   The 
initiator shall manage the address space so that the status FIFO and sense data buffer can be associated with 
a specific CDS.
The asynchronous event buffers are used if an initiator requests notification of asynchronous events during the 
login procedure.  The address of the AE buffers is specified in the LOGIN CDS.
9.1.   Status FIFO
The initiator shall provide the address of a status FIFO within each CDS.  The data structure sent to the status 
FIFO is defined in table 7.
Table 7 - Status block
Bytes
Function
0 to 3
CDS Address (msq)
4 to 7
CDS Address (lsq)
8 to 11
SCSI status 
Sense key
ASC
ASCQ
12 to 15
CDS status
Reserved
SBP status
IMPLEMENTOR NOTE:  The location of the status FIFO is implementation dependent.  If an 
initiator desires an interrupt when the status block is received then the FIFO may  be located 
within memory space that is capable of generating an interrupt.
The CDS address is the value contained in the address of this CDS field for the associated CDS.
The SCSI status, sense key, ASC and ASCQ are defined in the SCSI-3 Architectural Model standard and the 
SCSI-3 Primary Command Set standard. 
The CDS status is defined in table 8.
Table 8 - CDS status
Displacement
Description
0 to 4
Reserved
5
SCSI Status Invalid (SSI)
6
Sense data sent flag (SDS)
7
Tap slot available flag (TSA)
The SCSI status invalid (SSI) flag, when set, indicates that the SCSI status byte in the SBP status block is 
invalid. This flag is used when an abort function has been requested by the initiator.
The sense data sent (SDS) flag, when set, indicates that sense data has been transferred for the associated 
CDS.
The tap slot available (TSA) flag, when set to one, indicates that a tap slot previously used by the initiator is 
available. See tap slot allocation procedure (14.3). 
The SBP status is defined in table 9.
Table 9 - SBP status
Value
Description
00h
No status to report
01h-0Fh
Reserved
10h
Unsupported data rate requested
11h
CDS has mismatch in tap type and task attribute
12h
Tap rejected
13h
Login Error
14h-EFh
Reserved
F0h-FEh
Vendor-specific
FFh
Exception occurred but no status code defined
9.2.   CDS sense buffer
If the CDS sense length field contains a non-zero value the initiator shall provide a CDS sense buffer.  The 
data sent to the CDS sense buffer is defined in table 10.  The total length (i.e., the value of m) shall not 
exceed 65,535 bytes.  
NOTE: The format for bytes 0-23 is taken from the FCP document describing status return 
and is intended to provide for increased compatibility between FCP and SBP regarding format 
of status and sense data.
Table 10 - CDS sense data format
Bytes
Description
0 to 3
Reserved
4 to 7
Reserved
8 to 11
Status

12 to 15
Residual Count

16 to 19
REQUEST SENSE data length

20 to 23
Response length

24 to n
Response information

n+1 to m
REQUEST SENSE data
The status quadlet field (see table 11) is normally zero upon successful completion of a command.  A zero 
value indicates that no error occurred and no other information is present in the response information.   
Table 11 - Status quadlet
Byte
Description
0 
Reserved
1
Reserved
2
Valid flags

3
SCSI status
The valid flags field is defined in table 12.
Table 12 - Valid flags field
Displacement
Description
0
Reserved
1
Reserved
2
Reserved
3
Reserved
4
Residue field valid - under-run
5
Residue field valid - overrun
6
REQUEST SENSE information valid
7
Response information valid
The residue field valid - under-run flag indicates that requested amount of data transferred was less than the 
CDS transfer length.
The residue field valid - overrun flag indicates that the amount of data available to transfer was more than the 
CDS transfer length.
The request sense information valid flag indicates that REQUEST SENSE data is valid.
The response information valid flag indicates that the response information is valid.
The SCSI status is the status byte as defined by the SCSI-3 Architecture Model.  The status byte reported in 
the status block and that reported in the sense data shall be the same value for the CDS.
The residue field contains a count of the number of residual data bytes which were not transferred for this 
CDS.  This is the difference between the byte transfer length in the CDS and the  number of bytes that were or 
could have been transferred.  A residue of zero is normal upon successful completion.  Devices having 
indeterminate data lengths may have a non zero residue even with successful completion of the command.
The REQUEST SENSE data length field specifies the length of the of the REQUEST SENSE data.  The length 
shall be an integral multiple of four and not exceed 100h.  A length of zero indicates that REQUEST SENSE 
data  is not provided.  
Note - A REQUEST SENSE data length of zero is normal but not required upon successful 
completion of a command.
The response data length field specifies the length of the response information.  The length shall be an integral 
multiple of four.  A length of zero specifies that response information is not provided.  
Note - A response data length of zero is normal but not required upon successful completion 
of a command.
The sense information field contains the information specified by the SCSI-2 Standard for presentation by the 
REQUEST SENSE command.
The response information field is reserved.
9.3.   Asynchronous event buffer
If asynchronous event reporting is enabled the initiator shall provide a status FIFO and a sense data buffer for 
asynchronous event notification.  AE reporting is enabled through the login procedure.  See clause 15.1.
Each target shall have a unique address in the initiator for the status FIFO and sense data buffer used to 
report asynchronous events.  After reporting an asynchronous event, AE reporting is disabled until the initiator 
performs another login procedure.  The target shall not reuse the sense data buffer.

10.0.   Command data structures
All command data structures (CDS) formats are 72 bytes long.  A tap contains the first 64 bytes of a CDS.  
CDS's are transported from the initiator to a target either as the contents of a tap, or via a fetch protocol.  
When the target fetches a CDS, it may read all or any part (from 1 to 72 bytes).  See the definition of the 
target fetch protocol in clause 10 for more information.  A target may re-fetch a CDS until it returns a status 
block for that CDS.
The last eight bytes of all CDS formats contain the CDS sense buffer address field.  The target shall return 
CDS sense data to this sense buffer when using the auto sense procedure.
Some CDS formats contain an SCSI command descriptor block.  This is a 16-byte field designated as a 
CDB(0) through CDB(15).  This field shall contain a command descriptor block as defined in SCSI-2 or one of 
the SCSI-3 command set documents.
There are multiple formats of the CDS.  These formats are specified by the value of the function code in the 
CDS codes field.
10.1.   General CDS format
The general format of the Command Data Structure (CDS) is defined in table 13. The CDS format specific 
fields are defined for a specific use of the CDS within clauses 8 and 9.  Only those fields common to the CDS 
format are defined in this clause.
Table 13 - Command data structure format
Bytes
Description
0 to 3
Address of next CDS (msq)
4 to 7
Address of next CDS (lsq)
8 to 11
Address of this CDS (msq)

12 to 15
Address of this CDS (lsq)

16 to 19
Reserved
Identifier
Logical unit number
20 to 23
CDS codes
CDS specific
CDS specific
CDS specific
24 to 27
CDS format specific
28 to 31
CDS format specific

32 to 35
CDS format specific
36 to 39
CDS format specific
40 to 43
CDS transfer length
44 to 47
Data transfer control
CDS sense length
48 to 51
CDS format specific
52 to 55
CDS format specific
56 to 59
CDS status FIFO address (msq)
60 to 63
CDS status FIFO address (lsq)
64 to 67
CDS sense buffer address (msq)
68 to 71
CDS sense buffer address (lsq)
The address of next CDS field specifies the address of the next CDS in the chain.  Some CDS types do not 
allow chaining and as a result reserved this field.  See the specific CDS type for details.
The address of this CDS field specifies the address of this CDS.
The identifier field contains the initiator id returned by the target in response to the login request.
The logical unit number field specifies the logical unit number for this CDS.
Note:  The logical unit number field is defined as a 16-bit unsigned integer value within SBP.  
Other protocols using SCSI commands define the size of this field differently. The mechanism 
for dealing with the different size fields for logical units is not specified in this standard.
The CDS transfer length specifies the maximum size in bytes of the data transfer associated with this CDS.
The CDS sense length field specifies the size in bytes of the CDS sense data buffer.  It is an unsigned integer 
with a maximum value of FFFFh (i.e., 65,535 bytes of sense data).  If the CDS sense length value is zero, 
CDS sense data shall not be returned for this CDS via the auto sense procedure.
The CDS status FIFO address field contains the address to which the CDS status block is sent for this CDS.
The CDS sense buffer address field contains the address of the buffer associated with the CDS to which CDS 
sense data is returned.  The address in the CDS sense buffer address field is not valid if the CDS sense length 
field has a value of zero.  The target is not required to fetch the CDS sense buffer address field unless it needs 
to return CDS sense data for this CDS.  The format of the CDS sense data returned is defined in table 10.
10.1.1.   CDS codes field
The CDS codes field specifies format, CDS type, and tap type, of the CDS (see table 14)
Table 14 - CDS codes field
Displacement
Description
0 to 1
CDS identifier
2 to 4
Tap type
5 to 7
CDS type
The CDS identifier field specifies the format of the command data structure (CDS).  The values are defined in 
table 15.
Table 15 - CDS identifier
Value
Description
0h
Reserved
1h
Format specified Table 14
2h
Reserved
3h
Reserved
The tap type field specifies the tap associated with this CDS (see table 16).
Table 16 - Tap type
Value
Description
0h
Asynchronous normal tap
1h
Asynchronous login tap
2h
Asynchronous ACA tap
3h
Asynchronous urgent tap
4h
Isochronous normal tap
5h
Isochronous login tap
6h
Isochronous ACA tap
7h
Isochronous control tap
The CDS type field specifies the format of the CDS as defined in table 17.
Table 17 - CDS type field
Value
Description
0h
SCSI CDS
1h
Login CDS
2h
Management CDS
3h
Isochronous SCSI CDS
4h - 7h
Reserved
10.1.2.   Data transfer control field
The data transfer control field provides control information regarding transfer rate, alignment, and packet size 
as defined in table 18.
Table 18 - Data transfer control field
Displacement
Description
0 to 3
Reserved
4 to 7
Data transfer rate
8 to 11
Alignment
12 to 15
Maximum packet size
The data transfer rate field specifies the maximum speed to be used when transferring data. The values of this 
field are defined in table 19.
NOTE: The transfer rates of S100, S200, and S400 identify speeds that  are defined for IEEE 
1394 PHY data rates.
Table 19 - Data transfer rate
Value
Description
0h
Transport medium base rate
1h
S100
2h
S200
3h
S400
4h - Fh
Reserved
The alignment field indicates the address boundary which is not to be crossed by a single data transfer packet.  
A value of zero specifies that there are no restrictions on address boundary.  All other values, 0001b through 
and including 1111b represent the value of an exponent N such that, the number two (2) raised to the power 
(Decimal equivalent of N plus 1) represents the address boundary expressed in bytes. The limit case, is N=15 
Decimal, with the result that two raised to power 16 indicates an address boundary of 64 KBytes.
The maximum packet size field indicates the maximum size of packet to be used by the device in 
accomplishing a requested data transfer.  All  values, 0000b through and including 1111b represent the value 
of an exponent N such that, the number two (2) raised to the power (Decimal equivalent of N plus 1) 
represents the maximum size packet expressed in units of bytes.  The limit case, is N=15 Decimal, with the 
result that two raised to power 16 indicates an maximum packet size of 64 KBytes.
10.2.   SCSI CDS FORMATS
Two formats are defined below for SCSI CDS's. The two types of CDS's formats are identified as a SCSI CDS 
and an ISOCHRONOUS SCSI CDS. Both CDS type carry a SCSI CDB within the format.  The differences are 
identified below.
10.2.1.   SCSI CDS
The rules for handling CDB's, included in a SCSI CDS, are as follows:
1. The CDB carried by the CDS shall be entered into a task set (identified in SAM).
2. The rules governing the scheduling of execution of the CDB are specified in SAM.
3. No additional information governing scheduling of execution is required.
Table 20 defines the format for the SCSI CDS.  
Table 20 - SCSI CDS
Bytes
Description
0 to 3
Address of next CDS (msq)
4 to 7
Address of next CDS (lsq)
8 to 11
Address of this CDS (msq)

12 to 15
Address of this CDS (lsq)

16 to 19
Reserved
Identifier
Logical unit number
20 to 23
CDS codes
Task codes
 Reserved
Protocol flags
24 to 27
CDB 0
CDB 1
CDB 2
CDB 3
28 to 31
CDB 4
CDB 5
CDB 6
CDB 7

32 to 35
CDB 8
CDB 9
CDB 10
CDB 11
36 to 39
CDB 12
CDB 13
CDB 14
CDB 15
40 to 43
CDS transfer length
44 to 47
Data transfer control
CDS sense length
48 to 51
Data buffer address (msq)
52 to 55
Data buffer address (lsq)
56 to 59
CDS status FIFO address (msq)
60 to 63
CDS status FIFO address (lsq)
64 to 67
CDS sense data buffer address (msq)
68 to 71
CDS sense data buffer address (lsq)
The address of the next CDS is valid if the M-flag is set. (See 8.2.1. Protocol flags field)
The identifier field contains the initiator id returned by the target in response to the login request.
The task codes field for use with the SCSI CDS is defined in table 21.
Table 21 - Task codes field
Displacement
Description
0 to 4
Reserved
5 to 7
Task attribute
The task attribute field specifies the type of queue tag.  The values of this field are defined in table 22.  The 
task attributes are defined in the SCSI-3 Architecture Model standard.
Table 22 - Task attribute
Value
Description
0h
Simple
1h
Head of queue
2h
Ordered
3h
Reserved
4h
ACA
5h
Untagged
6h
Reserved
7h
Reserved
The protocol flags field is defined in  table 23.
Table 23 - Protocol flags field
Displacement
Description
0
Abort task flag (A)
1
Linked flag (L)
2
Data transfer order flag (O)
3
Scatter-gather flag (S)
4
next CDS address valid flag (M)
5
end of sub-chain flag (SCE)
6
Read data flag
7
Write data flag
The Abort task flag when set indicates the that this CDS shall be aborted. The Abort task flag is the only field 
that an initiator may modify once a tap for the chain contain the CDS has been sent. The initiator shall not 
clear the Abort task flag once it has been set until the target has released the affected CDS (via status or other 
action).
The Linked flag when set indicates that this is a linked CDS. This flag shall have a value of zero for the last 
CDS in a series of linked CDS's'. When the Linked flag is cleared, this is not a linked CDS.
Within a chain, once the Linked flag is set, all CDS's to the end of the chain shall have the Linked flag set. The 
Linked flag does not affect the function of the next CDS address valid flag. When the Linked flag is set, the 
end of sub-chain flag shall be cleared.
IMPLEMENTOR'S NOTE: The Linked flag, in conjunction with the linked bit in the command 
descriptor block, can be used to implement a SCSI style set of linked commands. However, 
the Linked flag affects the fetch policy regardless of the setting of the linked bit in the 
command descriptor block.
The Data transfer order flag when set to one indicates that the target shall transfer packets in sequential order 
to or from the initiator.  If this bit has value zero, the target may transfer packets out of order.
The Scatter-gather flag when set to one indicates that the initiator memory Scatter-gather function is being 
invoked for the present command.
When the Scatter-gather flag is cleared:
a)	the transfer length field contains the requested number of bytes of data to be transferred;
b)	the data buffer address field contains a 64-bit address that the data is transferred to or from.  This 
data address is not required to be associated with the initiator that sent the CDS.
When the Scatter-gather flag is set:
a)	the transfer length field indicates the size, in bytes, of the scatter-gather list found at the address 
specified by the value in the data buffer address.
b)	the data buffer address field contains the address of the scatter-gather list.  This address has no 
specific alignment restriction.
The scatter-gather list shall consist of one or more consecutive 16-byte constructs in the format shown in table 
24.
Table 24 - Scatter/gather list
Byte
Function
0
Data buffer address (msq)
4
Data buffer address (lsq)
8
Reserved
12
Transfer length
The data buffer address field contains an address that data is written to or read from.  This data address may 
or may not be associated with the initiator that sent the command.
The transfer length field contains the number of bytes which shall be transferred as a result of successful 
completion.
The M-flag when set indicates that the address of next CDS field contains the address of the next CDS in the 
chain.  The M_flag when cleared indicates that this CDS is the last CDS in the chain.  If the M-flag is cleared 
the SCE-flag is ignored.   If the M-flag is cleared and the link bit in the SCSI command descriptor block is set 
the command is terminated with CHECK CONDITION status.
The SCE-flag when set, indicates the end of a sub-chain and advances the time stamp for the remainder of 
the chain to the current time.  A CDS with the SCE flag set marks the end of one sub-chain.  If the M-flag is 
set in the current CDS the address of next CDS field contains the address of the first CDS in the next sub-
chain.  

10.2.2.   Isochronous SCSI CDS
The rules for handling CDB's, carried within an ISOCHRONOUS SCSI CDS, are as follows
1. The CDB carried by the CDS shall not be entered into any task set.
2. SAM does not provide rules governing the scheduling of execution of the CDB.
3. Scheduling of execution of the CDB is based on information contained in an Isochronous Control CDS.
Table 25 defines the format for the ISOCHRONOUS SCSI CDS.
Table 25 - ISOCHRONOUS SCSI CDS
Bytes
Description
0 to 3
Address of next CDS (msq)
4 to 7
Address of next CDS (lsq)
8 to 11
Address of this CDS (msq)

12 to 15
Address of this CDS (lsq)

16 to 19
Reserved
Identifier
Logical unit number
20 to 23
CDS codes
Reserved
 Reserved
Protocol flags
24 to 27
CDB 0
CDB 1
CDB 2
CDB 3
28 to 31
CDB 4
CDB 5
CDB 6
CDB 7

32 to 35
CDB 8
CDB 9
CDB 10
CDB 11
36 to 39
CDB 12
CDB 13
CDB 14
CDB 15
40 to 43
CDS transfer length
44 to 47
Data transfer control
CDS sense length
48 to 51
Reserved
52 to 55
Reserved
56 to 59
CDS status FIFO address (msq)
60 to 63
CDS status FIFO address (lsq)
64 to 67
CDS sense data buffer address (msq)
68 to 71
CDS sense data buffer address (lsq)
The address of the next CDS is valid if the M-flag is set. (See 8.2.1. Protocol flags field)
The identifier field contains the initiator id returned by the target.  All CDS's (Isochronous SCSI CDS and 
Isochronous Control CDS) having the same value in the identifier field are associated with the same 
isochronous stream. This identifier value is returned during the isochronous login operation.
The protocol flags field is defined in  table 26.
Table 26 - Protocol flags field
Displacement
Description
0
Abort task flag (A)
1
Reserved
2
Reserved
3
Reserved
4
next CDS address valid flag (M)
5
Reserved
6
Read data flag
7
Write data flag
The Abort task flag when set indicates the that this CDS shall be aborted. The Abort task flag is the only field 
that an initiator may modify once a tap for the chain contain the CDS has been sent. The initiator shall not 
clear the Abort task flag once it has been set until the target has released the affected CDS (via status or other 
action).
The M-flag when set indicates that the address of next CDS field contains the address of the next CDS in the 
chain.  The M_flag when cleared indicates that this CDS is the last CDS in the chain.  If the M-flag is cleared 
the SCE-flag is ignored.   If the M-flag is cleared and the link bit in the SCSI command descriptor block is set 
the command is terminated with CHECK CONDITION status.
10.3.   LOGIN CDS
The LOGIN CDS (table 27) performs the login function that allocates resources in a target and provides an 
identifier for the initiator to use.
Table 27 - LOGIN CDS
Bytes
Description
0 to 3
Reserved
4 to 7
Reserved
8 to 11
Address of this CDS (msq)

12 to 15
Address of this CDS (lsq)

16 to 19
Reserved
Identifier
Logical unit number
20 to 23
CDS codes
Reserved
Reserved
Login flags
24 to 27
Numerator
Denominator

28 to 31
Integer count
Number of slots
AE sense length
32 to 35
AE buffer address (msq)/Packet length
36 to 39
AE buffer address (lsq)
40 to 43
CDS transfer length
44 to 47
Data transfer control
CDS sense length
48 to 51
Data buffer address (msq)
52 to 55
Data buffer address (lsq)
56 to 59
CDS status FIFO address (msq)
60 to 63
CDS status FIFO address (lsq)
64 to 67
CDS sense buffer address (msq)
68 to 71
CDS sense buffer address (lsq)
The login flags are defined in table 28 below.
Table 28 - Login flags field
Displacement
Description
0
I-flag
1
Reserved
2
Reserved
3
Reserved
4
Reserved
5
Reserved
6
Reserved
7
Reserved
The I-flag, when set, indicates that the value in the identifier field is the proposed initiator identifier or stream 
identifier.  The I-flag when cleared, indicates that the target is requested to assign an initiator identifier or 
stream identifier.
If the I-flag is set, the identifier field contains the proposed identifier.  If the I-flag is cleared, the target shall 
ignore this field and assign an identifier.
The integer count, numerator, denominator and packet length fields apply only to the ISOCHRONOUS LOGIN 
CDS.
The integer count field specifies the number of isochronous data payload packets to send each isochronous 
cycle.
The numerator and denominator fields specify the effective fractional portion of an isochronous data payload 
packet to send each isochronous cycle
NOTE:  only whole isochronous data payload packets are sent each isochronous cycle; the 
data field of the isochronous data block packets which make up an isochronous channel 
alternate in size between I and I+1 isochronous data payload packets according to the values 
in the numerator and denominator fields.  See Annex C for more information.
The number of slots field identifies the number of tap slots requested by  this identified initiator.
The AE sense length specifies the length in bytes of the sense data to be returned to the initiator.
The packet length field defines the number of bytes in an isochronous data payload packet.
The AE buffer address specifies the location within initiator memory to which the AE sense data shall be sent.
The transfer length field specifies the length in bytes of the data to be returned to the initiator.  The data to be 
returned is defined in table 29.
Table 29 - LOGIN data format
Bytes
Function
0 to 3
Normal FIFO address (msq)
4 to 7
Normal FIFO address (lsq)
8 to 11
Urgent FIFO address (msq)

12 to 15
Urgent FIFO address (lsq)

16 to 19
ACA FIFO address (msq)

20 to 23
ACA FIFO address (lsq)

24 to 27
Reserved
Identifier

28 to 31
Prior tap slot count
New tap slot count
The normal FIFO address field contains the address of the normal command FIFO.
The urgent FIFO address field contains the address of the urgent command FIFO.
The ACA FIFO address field contains the address of the ACA command FIFO.
The identifier field contains the identifier assigned to the initiator.
The prior tap slot count field contains the number of tap slots assigned to the initiator at the time the LOGIN 
CDS was received.
The new tap slot count field contains the number of tap slots assigned to the initiator as a result of processing 
the LOGIN CDS.
The data buffer address field, in the Login CDS, is the location to which the returned data is sent.
10.4.   MANAGEMENT CDS
Table 30 - Management CDS
Bytes
Description
0 to 3
Reserved
4 to 7
Reserved
8 to 11
Address of this CDS (msq)

12 to 15
Address of this CDS (lsq)

16 to 19
Reserved
Identifier
Logical unit number
20 to 23
CDS codes
Reserved
Management flags
SBP flags
24 to 27
Reserved
28 to 31
Reserved

32 to 35
Tag value (msq)
36 to 39
Tag value (lsq)
40 to 43
CDS transfer length
44 to 47
Data transfer control
CDS sense length
48 to 51
Reserved
52 to 55
Reserved
56 to 59
CDS status FIFO address (msq)
60 to 63
CDS status FIFO address (lsq)
64 to 67
CDS sense buffer address (msq)
68 to 71
CDS sense buffer address (lsq)
The management flags field used with the management CDS is defined in table 31.
Table 31 - Management flags field
Displacement
Description
0
RESERVED
1
CLEAR ACA
2
TARGET RESET
3
RESERVED
4
TERMINATE TASK 
5
CLEAR TASK SET
6
ABORT TASK SET
7
ABORT TASK
The task management functions are defined in the SCSI-3 Architecture Model and in clause 6 of this 
document.
Table 32 - SBP flags field
Displacement
Description
0
Reserved
1
Reserved
2
Reserved
3
Reserved
4
Reserved
5
Reserved
6
Logout flag
7
Pause flag
The logout flag if set causes the target to release all the resources for the specified identifier.
The pause flag if set causes the target to suspend data transfer for the specified identifier.  The pause flag if 
cleared, causes the target to resume a suspended data transfer for the specified identifier.  If the pause flag is 
cleared and a suspended data transfer does not exist for the specified identifier then no action is required.
The tag value field contains the address of the CDS on which the management function is to be performed.
NOTE: The tag value field is valid only for the ABORT TASK function.
10.5   Isochronous control CDS
The Isochronous Control CDS has a CDS type of "Isochronous Control CDS" in the CDS type field.  The 
ISOCHRONOUS CONTROL CDS (table 31) shall be delivered to the isochronous urgent FIFO for the stream 
for which it applies.
Table 33 - ISOCHRONOUS CONTROL CDS
Bytes
Description
0 to 3
Address of next CDS (msq)
4 to 7
Address of next CDS (lsq)
8 to 11
Address of this CDS (msq)

12 to 15
Address of this CDS (lsq)

16 to 19
Reserved
Identifier
Logical unit number
20 to 23
CDS codes
Reserved
Reserved
Channel Number
24 to 27
Action
Stream Event
sy Synch/sy Trigger
sy default
28 to 31
SYNC Period

32 to 35
Seconds High Count
36 to 39
Seconds count/cycle count
40 to 43
CDS transfer length
44 to 47
Data transfer control
CDS sense length
48 to 51
Error Handling
Reserved
Reserved

52 to 55
Reserved
56 to 59
CDS status FIFO address (msq)
60 to 63
CDS status FIFO address (lsq)
64 to 67
CDS sense buffer address (msq)
68 to 71
CDS sense buffer address (lsq)
The ISOCHRONOUS CONTROL CDS requests the target to change the state (on or off) or characteristics of 
an isochronous stream.
The identifier field contains the initiator id returned by the target.  All CDS's (Isochronous SCSI CDS and 
Isochronous Control CDS) having the same value in the identifier field are associated with the same 
isochronous stream. This identifier value is returned during the isochronous login operation.
The Channel Number field only has meaning when the Action field contains a start action.  The target shall 
ignore this field for all other action codes.  The Channel Number field contains the isochronous channel 
number to use when the start action takes effect.  If the stream is not stopped, a start Isochronous Control 
CDS with a different channel number than the one currently in use will cause the target to change channel 
numbers based on the stream event field.
The Action field contains one of the following values:
Table 34 - Action Field
Value
Description
0h
Start
1h
Stop
2h
Pause
3h - FFh
Reserved
The requested action can be effective immediately, on a particular cycle number or on some other stream 
event, as specified by the value of the Stream Event field.
The start function tells the target to either begin talking or listening, or continue talking or listening at the place 
where it was paused.  The pause function does not affect the state of the stream of data; upon resuming, the 
target continues where it left off.
The pause action instructs the target to temporarily stop transferring a stream of isochronous data while 
maintaining context for that data transfer.  If the target is a talker, the target shall pause on the requested 
stream event and not send any data for that stream while in the paused state.  If the target is a listener, the 
target shall stop listening to the stream of data on the requested stream event.
The stream event field contains one of the following values:
Table 35 - Stream Event Field
Value
Description
0h
Immediately
1h
cycle number
2h
sy field match (listener only)
3h - FFh
Reserved
The immediately value instructs the target to perform the specified action as soon as possible, within the 
capabilities of the target implementation.
The cycle number value instructs the target to perform the specified action on the cycle number contained in 
the cycle number field of this CDS.
The sy field match value only has meaning when the target is acting as a listener.  The sy field match value 
instructs the target to perform the specified action on the isochronous cycle on which the isochronous packet 
header for the given channel number contains the sy value specified in the sy trigger field of this CDS.
The sy SYNC field and sy default field only have meaning when the target is acting as a talker.  See the 
description of the SYNC period field for definition.
The SYNC period field only has meaning when the target is acting as a talker.  The SYNC period determines 
the periodicity with which the target generates a synchronization packet.  A synchronization packet is one in 
which the sy field of the isochronous packet head has the value contained in the sy SYNC field of the Stream 
Control CDS.  For all isochronous packets which are not synchronization packets, the target shall set the sy 
field of the isochronous packet header to the value contained in the sy default field of the Isochronous Control 
CDS.  Note that the first isochronous packet that the target generates as a talker as the result of executing a 
start action is a synchronization packet.
Note:  The 'sy' field is a four bit field in the isochronous packet header which marks 
synchronization points in a stream of data.  This standard defines mechanisms for setting or 
triggering on any value in the sy field.  This standard does not define any meaning for any 
value in the sy field.
The seconds high count is a 25-bit field which has meaning only if the stream event field contains a value of 
cycle number event.  When valid, the seconds high count field contains a value to be compared against the 
seconds high count field of the Bus_Time register.  A cycle number match has occurred on the isochronous 
cycle on which these two fields are equal, and the values in the seconds Count/cycle Count fields are equal to 
the seconds count and cycle count fields of the cycle start packet.
The Error Handling field contains one of the following values:
Table 36 - Error Reporting Field
Value
Description
0
Report error and stop
1
Report error and continue
2
Ignore all errors
3-15
reserved
The definition for these values is described in the section below entitled "Isochronous Error Reporting".
11.0.   Control procedures
Additional protocols are required within the Serial SCSI environment to support the ability of the initiator to 
interact with targets regarding management of:
a)  tap slot resource
b)  sign-in for notification of asynchronous events
Targets are not allowed to respond to most SBP control protocol requests from an initiator unless that initiator 
has previously obtained from the target either an identifier from use with the asynchronous transfer protocol or 
a identifier from use with the isochronous transfer protocol.  The target is allowed to respond normally to an 
initiator without a valid identifier only when the request is for login.
11.1.   Login procedure
The login procedure is the method by which the initiator obtains an identifier and the FIFO addresses needed 
to deliver CDS's to the target.  The initiator shall not attempt to deliver any CDS's other than the login CDS 
prior to logging in.
The initiator may have multiple identifiers outstanding for a given target for both asynchronous login and 
isochronous login.
11.1.1.   Asynchronous login procedure
Using the tap protocol, the initiator sends an ASYNCHRONOUS LOGIN CDS to the target's asynchronous 
login FIFO requesting an identifier and the addresses for the FIFO needed to support the asynchronous 
command, control, status and data transfer protocols.
If the target is able to honor the initiator's login request, the target returns the following information to the 
initiator using the data transfer protocol:
a)  address of the normal command FIFO;
b)  address of the urgent command FIFO;
c)	  address of the ACA command FIFO;
d)  unique identifier.
The target then returns status for the asynchronous login CDS using the status transfer protocol.
If the target is unable to accept a login request, the target shall return sense data using the sense data transfer 
protocol, and then return status for the asynchronous login CDS using the status transfer protocol.
After successful completion of the asynchronous login request, the initiator may issue asynchronous CDS's to 
the target.
11.1.2.   Isochronous login procedure
Using the tap protocol, the initiator sends an ISOCHRONOUS LOGIN CDS to the target's isochronous login 
FIFO requesting an identifier and the addresses for the FIFO and registers needed to support the isochronous 
command, control, status and data transfer protocols.
If the target is able to honor the initiator's isochronous login request, the target returns the following information 
to the initiator using the data transfer protocol:
a)  address of the isochronous command FIFO;
b)  address of the isochronous control FIFO;
c)	  address of the isochronous ACA command FIFO;
d)  unique stream identifier.
The target then returns status for the isochronous login CDS using the status transfer protocol.
If the target is unable to accept an isochronous login request, the target shall return sense data using the sense 
data transfer protocol, then return status for the isochronous login CDS using the status transfer protocol.
After successful completion of the isochronous login request, the initiator may issue isochronous CDS's to the 
target.
11.1.3.   Tap slot allocation procedure
The tap slot allocation procedure provides an initiator the means to request a specific number of tap slots be 
reserved for its use.  A tap slot allocation request can be made as a part of the login procedure or at any time 
thereafter up until a logout procedure is performed for the identifier.  This allows the initiator to modify the 
number of tap slots it has been allocated to meet its workload requirements.  The LOGIN CDS is used for the 
tap slot allocation procedure.
There is no requirement upon an initiator to request allocation of tap slots prior to sending CDS's to the target.  
A target supporting asynchronous transfer operation shall support the tap slot allocation procedure.
Initiators are not required to limit their use of tap slots to the number they have been allocated. However, if all 
initiators using the target are cooperating by staying within their allocations, then the availability of their tap 
slots occurs as a natural consequence of operation. In all other cases, tap slot accesses may result in 
rejections. 
A target shall not limit an initiator to its allocated number of tap slots if additional tap slots are available in the 
unallocated pool of tap slots. A target that releases the tap slot at the first point serves to increase the effective 
number of tap slots relative to the number of command chains which can be serviced by the target. The target 
shall notify the initiator of the release of a tap slot by setting the tap slot available (TSA) flag in one of the SBP 
status blocks returned for a chain. The following rules govern the setting of this flag:
1.	The tap slot available flag is set in only one of the status blocks returned for a chain.
2.	When the tap slot available flag is set then the target shall have the tap slot for the associated chain 
available to accept a new tap.
3.	The tap slot available flag is set only for chains that are using allocated tap slots.  If the chain is not 
using an allocated tap slot then no tap slot available indication is returned.
4.	If a chain is using an allocated tap slot the target shall set tap slot available flag in a status block on 
or before completion of the chain.
Initiators are not limited in their use of tap slots to the number they have been allocated.  Initiators are not 
guaranteed availability of a tap slot even if they are within their allocation.
Cooperating initiators that limit themselves to using their allocated number of tap slots minimize the 
occurrence of a rejection due to a tap slot not being available.
11.2.   Logout procedure
The logout procedure is the method by which the initiator relinquishes an identifier and all resources 
associated with that identifier in a target.
The initiator performs the asynchronous logout procedure in order to release its assigned identifier, any sign-in 
reservations and any tap slot resources.  The initiator performs the isochronous logout procedure in order to 
release its assigned identifier and any resources previously reserved for isochronous data transfer for the 
associated stream.  The following sections describe these two procedures.
11.2.1.   Asynchronous logout
Using the tap protocol defined in this standard, the initiator sends a tap containing the management CDS with 
the logout flag set to the target's asynchronous login FIFO.  The target's configuration ROM contains the 
address of the asynchronous login FIFO.
The target returns a status block and then releases resources reserved for the identifier.  The resources 
include:
a)  tap slot allocations;
b)  sign-in reservations;
c)  normal, urgent and ACA FIFO's;
d)  initiator identifier.
After performing the asynchronous logout procedure, the initiator shall not use the identifier nor shall it deliver 
any asynchronous CDS's to the target using the normal, urgent or ACA command FIFO's which were released 
at the time of the asynchronous logout without performing another login.
11.2.2.   Isochronous logout
Using the tap protocol defined in this standard, the initiator sends a tap containing the management CDS with 
the logout flag set to the target's asynchronous login FIFO.  The target's configuration ROM contains the 
address of the isochronous login FIFO.
The target releases resources reserved for the identifier and returns a status block using the status transfer 
protocol defined in this standard.  The resources include:
a)  internal resources necessary to support the isochronous stream;
b)  sign-in reservations;
c)  the normal, urgent, and ACA FIFO's;
d)  stream identifier.
The target then returns status using the status transfer protocol.
After performing the isochronous logout procedure, the initiator shall not use the identifier nor shall it send any 
isochronous CDS's to the isochronous normal, urgent, or ACA FIFO's which were released at the time of the 
isochronous logout without performing another login.
11.3.   Sign-in procedure
A sign-in provides the initiator with the means to deal with asynchronous events.  An AE sense length greater 
than zero indicates that the initiator requests asynchronous event notification.  An AE sense length of zero 
indicates that the initiator requests notification of asynchronous events be terminated.  The LOGIN CDS is 
used for the sign-in procedure.  The initiator may sign-in as part of the initial login procedure or at later time.
The sign-in procedure applies to the occurrence of one asynchronous event.  When a target performs an 
asynchronous event notification all notified initiators perform a  sign-in procedure again to receive notification 
of the next asynchronous event.
An initiator may send to the target a second request for notification of asynchronous events even though a 
prior request for notification is still valid and in effect.  The new request supersedes the previous request with 
the new AE buffer address replacing the previous address.
The format of the sense data returned on an asynchronous event report is the same as it is in the SCSI-3 
REQUEST SENSE command.

Annex A   Configuration ROM (informative)
12.0.   Scope
The IEEE 1394 Serial Bus interface carries with it certain implementation requirements for CSR registers and 
configuration ROM information.  These register and ROM implementation requirements follow the IEEE 1212 
standard, which describes certain baseline registers and ROM entries and also defines a framework for 
additional registers and ROM entries for bus specific and device specific applications.
This annex provides a description of the configuration ROM for advisory purposes only.  An example of a 
simple implementation of SBP configuration ROM is provided.  The IEEE 1394 and IEEE 1212 documents 
define the registers and ROM entries required to support SBP.
The base configuration ROM structure exists at a 48-bit node identifier address (FFFF F000 040016) found in 
every IEEE 1394 node.
Table A-1 shows an example of SBP configuration ROM entries.  This is only an example and not a definitive 
statement of a compliant configuration ROM.  Note that the configuration ROM is parsed for pointers to the 
locations of the node unique ID, the unit directories, and the unit dependent directories.  The IEEE 1212 
document formally defines these registers, and the IEEE 1394 document describes the use of some of these 
registers in the IEEE 1394 environment. 
 

Figure A-1 - Configuration ROM Layout
Table A-1 - Example of SBP configuration ROM entries

Offset
Length
ROM Entry Name
Value
First
016
1
bus_info_length
0216
Quadlet
116
1
crc_length
1016

216
2
ROM_CRC_value
calculated
Bus_Info
416
4
'1394' in ASCII
31 33 39 3416
block
816
4
Node options
0000 000016

C16
2
directory length
00 0416

E16
2
Directory CRC
calculated

1016
1
Vendor ID key
0316

1116
3
Module Vendor ID
ID of module vendor
Root
1416
1
Node Capab. key
0C16
Directory
1516
3
Node Capabilities
00 83 8016

1816
1
Node Unique ID key
4D16

1916
3
Node Unique ID offset
00 00 FC16

1C16
1
Unit Directory Key
D116

1D16
3
unit directory off
00 00 0416
Node
2016
2
length of leaf
00 0216
Unique
2216
2
leaf CRC
calculated
ID
2416
4
unique_id_hi
serial number hi
leaf
2816
4
unique_id_lo
serial number lo

2C16
2
directory length
00 0316

2E16
2
directory CRC
calculated

3016
1
unit_sw_version key
1316
Unit
3116
3
unit_sw_version
SW version number
Directory
3416
1
unit_spec_id key
1216

3516
3
unit spec ID
Specifier ID

3816
1
unit dep dir key
D416

3916
3
unit dep dir offset
00 00 0116

3C16
2
Unit dep dir length
00 0216
Unit
3E16
2
directory CRC
calculated
Dependent
4016
1
asynchronous login FIFO key
01kk kkkk2
Directory
4116
3
offset of asynchronous login FIFO
00 40 0016

4416
1
isochronous login FIFO key
01kk kkkk2

4516
3
offset of isochronous login FIFO
00 40 0016
The text below describes the parameters in the table above.  Much of this text is implementation specific.  
Please refer to the IEEE 1212 and IEEE 1394 documents for a more formal and general description of these 
registers.
12.1.   First quadlet
bus_info_length is the length, in quadlets, of the Bus_Info_Block portion of the data structure.
crc_length is the number of quadlets over which the following CRC is calculated.  In this case, the following 
CRC field protects the entire data structure shown in the above table.
ROM_CRC_value is calculated on the number of quadlets contained in the crc_length field, beginning with the 
quadlet immediately following the ROM_CRC_value field.
12.2.   Bus information block
'1394' in ASCII defines this to be a 1394 device.
Node options contains a field of bits which determine the 1394 options that this device implements.  The 
example value shown in the table above indicates that this device implements no options.  (Note that most of 
these options have to do with isochronous data transfer and bus management capabilities).
12.3.   Root directory
directory length is the length, in quadlets, of the root directory.  This length does not include the first quadlet 
in the root directory.
Directory CRC is calculated on the entire root directory(i.e., directory length quadlets, beginning with the 
quadlet immediately following the Directory CRC entry).
Vendor ID key indicates that the low order 24 bits of this quadlet contain the vendor ID.
Module Vendor ID is the 24 bit identification number of the vendor of this module.
Node Capab. key indicates that the low order 24 bits of this quadlet contain a field of bits defined in IEEE 
1212 which indicate the capabilities of this node.
Node Capabilities describes the capabilities of this node.  The bit settings appearing in the table above 
indicate that this device has the following capabilities:
spt bit set indicating that this device implements a split time-out register in the core register block.
64 bit set indicating that this node uses 64 bit addressing.
fix bit set indicating that this node implements the fixed addressing scheme.
lst bit set indicating that this node implements the lost bit in the state bits register (accessed using the 
State_Set and State_Clear registers in the core register block.
Note that these capabilities represent a minimal baseline feature set.
Node Unique ID key indicates that the low order 24 bits of this quadlet contain the offset to the node unique 
ID leaf.
Node Uniq ID offset contains the offset, in quadlets, from this entry to the node unique ID leaf.
Unit Directory Key indicates that the low order 24 bits of this quadlet contain the offset from this entry to the 
unit directory.
unit directory off contains the offset, in quadlets, from this entry to the unit directory.
12.4.   Node unique ID leaf
length of leaf contains the number of quadlets in this leaf.
leaf CRC contains the CRC of this leaf, calculated beginning with the next quadlet and continuing for length 
of leaf quadlets.
unique_id_hi contains the most significant quadlet of the node unique ID number.  The unique ID field 
contains is a serial number unique for all nodes manufactured by the vendor whose ID appears in the vendor 
ID field.
unique_id_lo contains the least significant quadlet of the node unique ID number.
12.5.   Unit directory
directory length contains the number of quadlets in this directory entry.
directory CRC contains the CRC of this directory, calculated beginning with the next quadlet and continuing 
for directory length quadlets.
unit_sw_version key indicates that the low order 24 bits of this quadlet contain the software version number 
for this node.
unit_sw_version contains the version of the software of this device.
unit_spec_id key indicates that the low order 24 bits of this quadlet contain the vendor ID of the entity 
defining the architectural interface of this node.
unit spec ID contains the identification number of the entity defining the architectural interface of this unit.
unit dep dir key indicates that the low order 24 bits of this quadlet contain the offset from this entry, in 
quadlets, of the unit dependent directory.
unit dep dir offset contains the offset from this entry, in quadlets, of the unit dependent directory.
12.6.   Unit dependent directory
Unit dep dir length contains the number of quadlets in this directory entry.
directory CRC contains the CRC of the data in this directory calculated beginning with the next quadlet and 
continuing for unit dep dir length quadlets.
asynchronous login FIFO key indicates that the low order 24 bits of this quadlet contain the offset, in 
quadlets, from the base of CSR space to the asynchronous login FIFO.  The presence of the asynchronous 
login FIFO entry in the unit dependent directory indicates that the target implements and supports all 
mandatory elements of the asynchronous data transfer protocol.
offset of asynchronous login FIFO contains the offset, in quadlets, from the base of CSR space to the 
asynchronous login command FIFO.
isochronous login FIFO key indicates that the low order 24 bits of this quadlet contain the offset, in quadlets, 
from the base of CSR space to the isochronous login FIFO.  The presence of the isochronous login FIFO entry 
in the unit dependent directory indicates that the target implements and supports all mandatory elements of 
the isochronous data transfer protocol.
offset of isochronous login FIFO contains the offset, in quadlets, from the base of CSR space to the 
isochronous login command FIFO.
12.7.   Asynchronous  and isochronous login FIFOs
Note that this FIFO is located at the same address as the isochronous login FIFO described below.  These two 
FIFO's may also be implemented at addresses different from each other.

Annex B  Examples (informative)
13.0.   Command processing
This section details a few typical commands being processed by a single initiator and target.  Note, not all 
packet acknowledge (acks) are shown in the diagrams to make them more readable. 
It has been the intention in drawing up this document to maintain as close a compatibility with parallel SCSI, as 
defined by the SCSI-2 specification as possible. There are the obvious changes in delivery of packets as 
described above but other than that it is the intention that any SCSI CDB could be delivered and any data 
could be sent and received with higher level microcode without the target and the initiator being aware of the 
change from a parallel interface to the serial.
13.1.   Target read command
This example shows a read command to a simple low-cost target which can process a single command at a 
time with no queuing in the target.  In this example the amount of data requested for transfer from the target to 
the initiator is sufficiently small that it can be accommodated in a single data packet. Should a larger amount 
of data be involved, then the target would send multiple data packets, such that one packet at a time is sent at 
each appropriate IEEE 1394 bus arbitration interval won by that target.  The data transfer process ends when 
all of the requested data has been sent. The target is responsible for making appropriate changes in the 
destination offset address to reflect the progress made in filling the data buffer in initiator memory.

           Initiator                                          Target
           ------------- Initiator taps target ------------
           Block Write Packet        ------>
           Address=Normal FIFO
           Data=First CDS
                                    Data=CDS
                                  M_flag=0
                                    <------  Ack (complete, busy, or pending)
                              <- - -   Block Write Response Packet
                                               (only if ack = pending)

           -------------- Target returns data read ------------------
                                     <-----   Block Write Packet
                                              Address=Data Address
                                              Data =Requested data
           Ack (complete, busy, or pending,    ------>
           Block Write Response        - - ->
      (only  if Initiator ack=pending)

           -------------- Target returns status ---------------------
                                     <------  Block Write Packet
                                              Address=Status FIFO
                                              Data=Status Block
           Ack (complete, pending,     ------>
                   or, busy)
           Block Write Response         - - ->
      (only if Initiator ack=pending)
Figure B-1 - Target read command

13.2.   Target multiple read commands
This example shows two read commands being issued to a target which can internally queue commands.  
Note that multiple data packets may be required to complete the data transfer for each command.
          Initiator                                           Target
           ------------- Initiator taps Target ------------
           Block Write Packet        ------>
           Address=Normal FIFO
           Data=Address of Next CDS
                                    Data=CDS   M_flag=1
                                    <------   Ack (complete, busy, or pending)
                                    <- - - -  Block Write Response Packet
                                               (optional if ack=pending)
           -------------- Target requests next CDS ---------------
                                    <-----    Block Read Request Packet
                                              Address=2nd CDS 
           Ack (e.g. pending)        ------>
           Block Read Response       ------>
           Data=CDS #2, M_FLag=1
           -------------- Target requests next CDS ---------------
                                    <-----    Block Read Request Packet
                                              Address=Next CDS Address
           Ack (e.g. pending)        ------>
           Block Read Response       ------>
           Data=CDS #3, M_flag=0
           ----------- Target returns data read for cmd #1 ----------
                                    <------   Block Write Packet
                                              Address=Data Address #1
                                              Data =Requested data
           Ack (complete, pending,   ------>
                   or, busy)
           Block Write Response       - - ->
      (optional if Initiator ack=pending)
           ------------ Target returns status for cmd #1 -------------
                                    <------   Block Write Packet
                                              Address=Status Address #1
                                              Data=Status Block
           Ack (complete, pending,   ------>
                   or, busy)
           Block Write Response       - - ->
      (optional if Initiator ack=pending)
           ----------- Target returns data read for cmd #2 ----------
                                    <------   Block Write Packet
                                              Address=Data Address #2
                                              Data =Requested data
           Ack (complete, pending,   ------>
                   or, busy)
           Block Write Response       - - ->
      (optional if Initiator ack=pending)
           ------------ Target returns status for cmd #2 -------------
                                    <------   Block Write Packet
                                              Address=Status Address #2
                                              Data=Status Block
           Ack (complete, pending,   ------>
                   or, busy)
           Block Write Response       - - ->
      (optional if Initiator ack=pending)
Figure B-2 - Target multiple read commands

Annex C  ISOCHRONOUS TRANSFERS (Informative)
14.0.   Isochronous Transfers
This section describes the algorithm by which the talker determines the length, in bytes, of the data field of 
each isochronous data block packet.
14.1.   Definitions
The following terms are unique to Isochronous transfers.
talker - the source of the isochronous data being transferred on a given isochronous channel number. 
There shall only be at most 1 talker per isochronous channel number.
listener - the destination of the isochronous data being transferred on a given isochronous channel 
number. There may be zero, one or more than one listeners per isochronous channel number.
isochronous data block packet - a packet whose format is defined in the 1394 standard.
isochronous data payload packet - a packet which is carried as payload in an isochronous data block 
packet and whose format is application specific.
As required by the 1394 standard, there shall be at most one isochronous data block packet per channel per 
isochronous cycle.
SBP requires that there shall be an integer number of isochronous data payload packets per 
isochronous data block packet.  Isochronous data payload packets shall not be split across multiple 
isochronous data block packets.
14.2.   Isochronous Data Packetization
The talker transmits 8,000 Isochronous data block packets per second.  Each of these packets carries an 
integer number of isochronous data payload packets.  In order to emulate data rates which are not multiples of 
8,000 isochronous data payload packets per second, a talker sends isochronous data block packets having 
data fields of more than one length.
The ISOCHRONOUS LOGIN CDS contains 4 parameters that define an isochronous data rate.  These 
parameters are:
I = value in the integer count field
N = value in the numerator field
D = value in the denominator field
L = value in the packet length field
With the following restrictions:
I, N and D are non-negative integers
N shall be less than D (If N is zero, D shall be ignored)
L shall be greater than zero
For this discussion we define another parameter, R, as follows:
R = isochronous data rate in units of isochronous data payload packets per second
R is related to I, N and D as follows:
R = (I + N/D) * 8000
The isochronous rate in units of bytes per second is:
bytes per second = R * L
As an example, assume that a talker is configured to send 1 isochronous channel of digital audio data.  
Assume that the isochronous data payload packet length is 4 bytes and the rate is 44,100 isochronous data 
payload packets per second.  The resulting isochronous rate is:
L = 4
R = 44,100 = (I + N/D) * 8,000
Given the constraints on the values of I, N and D, their values are completely determined.
44,100/8,000 = I + N/D
I = 5
N = 41
D = 80
L = 4
The talker supports this rate by sending isochronous data block packets of length 5 isochronous data payload 
packets alternating with isochronous data block packets of length 6 isochronous data payload packets.
Every 80 cycles, the talker transmits an extra isochronous data block packet of length 6 isochronous data 
payload packets.
Over the course of D (80) isochronous cycles the number of isochronous data block packets transmitted is 
exactly what is required to sustain the desired isochronous data rate.
Page ii	PROPOSED working draft SCSI-3 Serial Bus Protocol

X3T10/992D revision 19

X3T10/992D revision 19

Page 14	dpANS SCSI-3 Serial Bus Protocol

dpANS SCSI-3 Serial Bus Protocol	Page 1


