Internet-Draft J. Satran
`<draft-satran-iscsi-01.txt> D. Smith
`Expires January 10, 2001 K. Meth
` IBM
`
` C. Sapuntzakis
` Cisco Systems
`
` Randy Haagens
` Hewlett-Packard Co.
`
` Efri Zeidner
` SANGate
`
` Paul Von Stamwitz
` Adaptec
`
` Luciano Dalle Ore
` Quantum
`
` July 10, 2000
`
` iSCSI (Internet SCSI)
`
`Status of this Memo
`
` This document is an Internet-Draft and is in full conformance with
` all provisions of Section 10 of RFC2026. Internet-Drafts are work-
` ing documents of the Internet Engineering Task Force (IETF), its
` areas, and its working groups. Note that other groups may also dis-
` tribute working documents as Internet-Drafts. Internet-Drafts are
` draft documents valid for a maximum of six months and may be
` updated, replaced, or obsoleted by other documents at any time. It
` is inappropriate to use Internet-Drafts as reference material or to
` cite them other than as "work in progress."
`
` The list of current Internet-Drafts can be accessed at
` http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
` Draft Shadow Directories can be accessed at
` http://www.ietf.org/shadow.html.
`
`Acknowledgements
`
` A large group of people contributed through their review, comments
` and valuable insights to the creation of this document - too many
` to mention them all. Nevertheless, we are grateful to all of them.
` We are especially grateful to those that found the time and
`
`Satran, Smith, Sapuntzakis, Meth [Page 1]
`
`Ex.1057.001
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` patience to participate in our weekly phone conferences and inter-
` mediate meetings in Almaden and Haifa and thus helped shape this
` document: Matt Wakeley (Agilent), Jim Hafner, John Hufferd, Prasen-
` jit Sarkar, Meir Toledano, John Dowdy, Steve Legg, Alain Azagury
` (IBM), Dave Nagle (CMU), David Black (EMC), John Matze (Veritas),
` Mark Bakke, Steve DeGroote, Mark Shrandt (NuSpeed), Gabi Hecht
` (Gadzoox), Robert Snively (Brocade), Nelson Nachum (StorAge)
`
`Table of Contents
`
`Satran, Smith, Sapuntzakis, Meth [Page 2]
`
`Ex.1057.002
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` 1. Abstract
` 2. Overview
` 2.1. SCSI Concepts
` 2.2. iSCSI Concepts & Functional Overview
` 2.2.1 Layers & Sessions
` 2.2.2 Ordering & iSCSI numbering
` 2.2.3 iSCSI Login
` 2.2.4 iSCSI Full Feature Phase
` 2.2.5 iSCSI Connection Termination
` 2.2.6 Naming & mapping
` 3. Message Formats
` 3.1. Template Header
` 3.2. SCSI Command
` 3.3. SCSI Response
` 3.4. NOP-Out Message
` 3.5. NOP-In Message
` 3.6. Asynchronous Event
` 3.7. SCSI Task Management Message
` 3.8. SCSI Task Management Response
` 3.9. Ready To Transfer (RTT)
` 3.10. SCSI Data
` 3.11. Text Command
` 3.12. Text Response
` 3.13. Login Command
` 3.14. Login Response
` 3.15. Ping Command
` 3.16. Ping Response
` 3.17. Map Command
` 3.18. Map Response
` 3.19. Third Party Commands
` 3.20. Opcode Not Understood
` 4. Error Handling iSCSI
` 5. Notes to Implementors
` 5.1. Small TCP Segments
` 5.2. Multiple Network Adapters
` 5.3. Autosense
` 5.4. Data Connections Options
` 6. Security Considerations
` 6.1. Data Integrity
` 6.2. Network operations & the threat model
` 6.3. IANA Considerations
` 7. Authors’ Addresses
` 8. References and Bibliography
` 9. Appendix A - Examples
` 9.1. Read operation example
` 9.2. Write operation example
` 10. Appendix B - Login/Text keys
`
`Satran, Smith, Sapuntzakis, Meth [Page 3]
`
`Ex.1057.003
`
`DELL
`
`

`

`
`iSCSI June 2000
`
`1. Abstract
`
` The Small Computer Systems Interface (SCSI) is a popular family of
` protocols for communicating with I/O devices, especially storage
` devices. This memo describes a transport protocol for SCSI that
` operates on top of TCP. The iSCSI protocol aims to be fully com-
` pliant with the requirements laid out in the SCSI Architecture
` Model - 2 [SAM2] document.
`
`2. Overview
`
`2.1. SCSI Concepts
`
` The endpoint of most SCSI commands is a "logical unit" (LU). Exam-
` ples of logical units include hard drives, tape drives, CD and DVD
` drives, printers and processors. Within the logical unit the
` abstract entity that executes the SCSI commands is named the
` device-server. A "target" is a collection of logical units, in
` general of the same kind, and is directly addressable on the net-
` work. In large installations a target is known also as a "control
` unit". The target corresponds to the server in the abstract SAM
` client-server model. An "initiator" creates and sends SCSI com-
` mands to the target. The initiator corresponds to the client in the
` abstract SAM client-server model. A "task" is a linked set of SCSI
` commands. Some LUNs support multiple pending (queued) tasks. The
` target uses a "task tag" to distinguish between tasks. Only one
` command in a task can be outstanding at any given time. A SCSI
` command results in an optional data phase and a response phase. In
` the data phase, information travels either from the initiator to
` the target, as in a WRITE command, or from target to initiator, as
` in a READ command. In the response phase, the target returns the
` final status of the operation, including any errors. A response
` terminates a SCSI command.
`
`2.2. iSCSI Concepts & Functional Overview
`
`2.2.1. Layers & Sessions
`
` The following conceptual layering model is used in this document to
` specify initiator and target actions and how those relate to
` transmitted and received Protocol Data Units: - SCSI layer
` builds/receives SCSI CDB (Command Data Blocks) and relays/receives
` them with the remaining command execute parameters (cf. SAM-2)
` to/from the - iSCSI layer that builds/receives iSCSI PDUs and
` relays/receives them to/from - one or more TCP connections that
` form an initiator-target "session"
`
` Communication between initiator and target occurs over one or more
`
`Satran, Smith, Sapuntzakis, Meth [Page 4]
`
`Ex.1057.004
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` TCP connections. The TCP connections are used for sending control
` messages, SCSI commands, parameters and data within iSCSI Protocol
` Data Units (iSCSI PDU). The group of TCP connections linking an
` initiator with a target form a session (loosely equivalent to a
` SCSI nexus); a session is defined by a session ID (composed of an
` initiator part and a target part). TCP connections can be added and
` removed from a session.
`
`2.2.2. Ordering and iSCSI numbering
`
` iSCSI supports ordered command delivery within a session. All com-
` mands (initiator-to-target) and responses (target-to-initiator) are
` numbered. Any SCSI activity is related to a task (SAM-2). The task
` is identified by the Initiator Task Tag for the life of the task.
`
` Commands in transit from the initiator SCSI layer to the target
` SCSI layer are numbered by iSCSI and the number is carried by the
` iSCSI PDU as CmdRN (Command-Reference-Number). All iSCSI PDUs that
` have a task association carry this number. CmdRNs are allocated by
` the initiator iSCSI as an increasing counter wrapping around from
` 2**32-1 to 1. The 0 value is reserved and used to mean immediate
` delivery. The target may choose to deliver some task management
` commands for immediate delivery. The means by which the SCSI layer
` may request immediate delivery for a command or by which iSCSI will
` decide by itself to mark a PDU for immediate delivery are yet to be
` defined. CmdRNs are significant only during command delivery to the
` target. Once the device serving part of the target SCSI has
` received a command, CmdRN ceases to be significant. The initiator
` and target are assumed to have three registers that define the
` allocation mechanism - CmdRN - the current command reference number
` advanced by 1 on each command shipped; ExpCmdRN - the next expected
` command by the target - acknowledges all commands up to it;
` MaxCmdRN - the maximum number to be shipped - defines the queuing
` capacity of the receiving iSCSI. CmdRN can take any value from
` ExpCmdRN to MaxCmdRN except 0. The target will reject any command
` outside this range or duplicates within the range not flagged with
` the retry bit (the X bit in the opcode). The target and initiator
` registers are supposed to uphold causal ordering.
`
` Responses in transit from the target to the initiator are also num-
` bered. The StatRN (Status Reference Number) is used for this pur-
` pose. If the target uses data packet numbering and all the inbound
` data have been acknowledged, or the target is able to regenerate
` inbound data, then the target may free all the resources allocated
` for the task execution just after sending a response. The same
` holds for targets not allowing full command recovery. The result
` summary, just enough to rebuild the status PDU, will be kept by
` those iSCSI target implementations that support status recovery
`
`Satran, Smith, Sapuntzakis, Meth [Page 5]
`
`Ex.1057.005
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` after connection failure. As the only cause for long delays in
` responses can be failed connections and received responses free-up
` resources, we felt that score boarding responses at the initiator
` could be accomplished by simple bitmaps and there is no need to
` flow-control responses. Status acknowledgment is done by the ini-
` tiator through ExpStatRN (Expected Status RN) and large difference
` between StatRN and ExpStatRN indicates a failed connection.
`
` iSCSI initiators are required to implement the numbering scheme if
` they support more than one connection.
`
` iSCSI targets are not required to use the numbering scheme for
` ordered delivery even when they support multiple connections. How-
` ever they are required to provide ExpCmdRN and MaxCmdRN values that
` will enable the initiator to make progress.
`
` The NOP PDUs are not associated with a task, are meant for immedi-
` ate delivery, and their only purpose is synchronizing the ordering
` registers of the target and initiator.
`
`2.2.3. iSCSI Login
`
` The purpose of iSCSI login is to enable a TCP connection for iSCSI
` use, authenticate the parties, authorize the initiator to send SCSI
` commands and mark the connection as belonging to a iSCSI session.
` A session is used to identify to a target all the connections with
` a given initiator. The targets listen on a well-known TCP port for
` incoming connections. The initiator begins the login process by
` connecting to that well-known TCP port. As part of the login pro-
` cess, the initiator and target MAY wish to authenticate each other.
` This can occur in many different ways. For example, the endpoints
` may wish to check the IP address of the other party. If the TCP
` connection uses transport layer security [TLS], certificates may be
` used to identify the endpoints. Also, iSCSI includes commands for
` identifying the initiator and passing an authenticator to the tar-
` get (see Appendix B). Once suitable authentication has occurred,
` the target MAY authorize the initiator to send SCSI commands. How
` the target chooses to authorize an initiator is beyond the scope of
` this document. The target indicates a successful authentication
` and authorization by sending a login response with "accept login".
` The login message includes a session ID - composed with an initia-
` tor part ISID and a target part TSID. For a new session the TSID is
` null. As part of the response the target will generate a TSID.
` Session specific parameters can be specified only for the first
` login of a session (TSID null)(e.g., the maximum number of connec-
` tions that can be used for this session). Connection specific
` parameters (if any) can be specified for any login. Thus a session
`
`Satran, Smith, Sapuntzakis, Meth [Page 6]
`
`Ex.1057.006
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` is operational once it has at least one connection. After authen-
` tication and authorization, other parameters may be negotiated
` using the highly extensible Text Command message that allows arbi-
` trary key:value pairs to be passed. Any message sent on a TCP con-
` nection before this connection gets into full feature phase at the
` initiator should be rejected by the initiator. A message reaching
` a target on a TCP connection before the full feature phase will be
` rejected with an iSCSI check condition.
`
`2.2.4. iSCSI Full Feature Phase
`
` Once the initiator is authorized to do so, the iSCSI session is in
` iSCSI full feature phase. The initiator may send SCSI commands and
` data to the various LUNs on the target by wrapping them in iSCSI
` messages that go over the established iSCSI session. For SCSI com-
` mands that require data and/or parameter transfer, the (optional)
` data and the status for a command must be sent over the same TCP
` connection that was used to deliver the SCSI command (connection
` allegiance). Thus if an initiator issues a READ command, the tar-
` get must send the requested data followed by the status to the ini-
` tiator over the same TCP connection that was used to deliver the
` SCSI command. If an initiator issues a WRITE command, the initia-
` tor must send the data for that command and the target must return
` the status over the same TCP connection that was used to deliver
` the SCSI command. During iSCSI Full Feature Phase, the initiator
` and target may interleave unrelated SCSI commands, their SCSI Data
` and responses, over the session. Outgoing SCSI data (initiator to
` target - user data or command parameters) is sent as either unsoli-
` cited data or solicited data. Unsolicited data can be part of an
` iSCSI command PDU ("immediate data") or an iSCSI data PDU. Soli-
` cited data are sent in response to Ready To Transfer PDUs. Targets
` operate in either solicited (RTT) data mode or unsolicited (non
` RTT) data mode. An initiator must always honor an RTT data
` request. It is considered an error for an initiator to send unsol-
` icited data PDUs to a target operating in RTT mode (only solicited
` data). An initiator is allowed to send immediate data even to tar-
` gets working in RTT mode. An initiator may request, at login, to
` send immediate data of any size and a target may indicate the size
` of immediate data blocks it is ready to accept in its response. A
` target is allowed to silently discard data and request retransmis-
` sion through RTT. Initiators will not perform any score boarding
` for data and the residual count calculation is to be performed by
` the targets. Incoming data is always solicited. However an initia-
` tor will be able to request retransmission of all or part of the
` target data. SCSI Data packets are matched to their corresponding
` SCSI commands by using Tags that are specified in the protocol.
` Initiator tags for pending commands are unique initiator-wide for a
` session. Target tags for pending commands are unique target-wide
`
`Satran, Smith, Sapuntzakis, Meth [Page 7]
`
`Ex.1057.007
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` for the session. Although the above mechanisms are designed to
` accomplish efficient data delivery and a large degree of control
` over the data flow it is recognized that some specific sequences
` involving ordered execution and a mix of solicited and immediate
` data can result in deadlocks. It is for this reason that discarding
` data by a target is considered a legitimate action. Each iSCSI ses-
` sion to a target is treated as if it originated from a different
` initiator.
`
`2.2.5. iSCSI Connection Termination
`
` Connection termination is assumed to be an exceptional event.
` Graceful TCP connection shutdowns are done by sending TCP FINs.
` Graceful connection shutdowns MUST only occur when there are no
` outstanding tasks that have allegiance to the connection. A target
` SHOULD respond rapidly to a FIN from the initiator by closing its
` half of the connection as soon as it has finished all outstanding
` tasks that have allegiance to the connection. Closing a connection
` that has outstanding tasks may require recovery actions and will Be
` described elsewhere in this document.
`
`2.2.6. Naming & mapping
`
` Targets are named using an URL type name of the format:
`
` scsi://<domain-name>[/modifier]
`
` The name used to connect will be optionally included in the login
` in order to enable the target to present different views. This is
` the Target Acquired Name (TAN). We will not attempt to define
` which components of the name will participate in the name resolu-
` tion process and which ones will be used only for "view" defini-
` tion. The syntactic sugar included might be used to introduce
` structure for management purposes but has no specific significance
` for this standard. Example:
`
` scsi://diskfarm1.acme.com
` scsi://computingcenter.acme.com/peripherals/diskfarm1
`
` When a target has to act as an initiator for a third party command
` it will use the TAN during login as required by the authentication
` mechanism. A domain name that contains exactly four numbers
` separated by dots (.), where each number is in the range 0 through
` 255, will be interpreted as an IPv4 address. Examples:
`
`Satran, Smith, Sapuntzakis, Meth [Page 8]
`
`Ex.1057.008
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` 10.0.0.1/tapefarm1
` 10.0.0.2
`
` Likewise a domain name that contains more than four, but less than
` 16 numbers separated by dots (.), where each number is in the range
` 0 through 255, will be interpreted as an Ipv6 address. Examples:
`
` 12.5.7.10.0.0.1/tapefarm1
` 12.5.6.10.0.0.2
`
` To address targets and logical units within a target SCSI uses a
` fixed length (8 bytes) uniform addressing scheme; in this document
` we call those addresses SCSI reference addresses (SRA).
`
` To provide the target with the protocol specific addresses (iSCSI
` or FC) iSCSI uses a Map Command; the Map command sends the managing
` target the protocol specific addresses and gets from the target the
` SRAs to use in subsequent commands. For iSCSI a protocol specific
` address is a TCP address and a view; those can be expressed as
` numeric IPV4 or IPV6 address+port sequences (6 or 18 bytes) fol-
` lowed by a view or in text form. After mapping iSCSI will be pro-
` vided with a handle to the address in standard SCSI format.
`
`Satran, Smith, Sapuntzakis, Meth [Page 9]
`
`Ex.1057.009
`
`DELL
`
`

`

`
`iSCSI June 2000
`
`3. Message Formats
`
` All multi-byte integers specified in formats defined in this docu-
` ment are to be represented in network byte order (i.e., big
` endian).
`
`3.1. Template Header and Opcodes
`
` All iSCSI messages and responses have a header of the same length
` (48 bytes). Additional data may be added, as necessary, beginning
` with byte 48. The fields of Opcode and Length appear in all message
` and response headers. The other most commonly used fields are Ini-
` tiator Task Tag, Logical Unit Number, and Flags, which, when used,
` always appear in the same location of the header.
`
` Byte / 0 | 1 | 2 | 3 |
` / | | | |
` |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
` +---------------+---------------+---------------+---------------+
` 0| Opcode | Opcode-specific fields |
` +---------------+---------------+---------------+---------------+
` 4| Length of Data (after 48 byte Header) |
` +---------------+---------------+---------------+---------------+
` 8| LUN or Opcode-specific fields |
` + +
` 12| |
` +---------------+---------------+---------------+---------------+
` 16| Initiator Task Tag |
` +---------------+---------------+---------------+---------------+
` 20/ Opcode-specific fields /
` +/ /
` +---------------+---------------+---------------+---------------+
` 48
`
`3.1.1. Opcode
`
` The Opcode indicates which iSCSI type of message or response is
` encapsulated by the header. The opcode is further encoded as fol-
` lows:
` b7 Retry Command/Response (X bit)
` b6 Response
` b5-0 Operation
`
` Valid opcodes for messages (sent by initiator to target) are:
` 0x00 NOP-Out Message (from initiator to target)
` 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block)
` 0x02 SCSI Task Management Command
`
`Satran, Smith, Sapuntzakis, Meth [Page 10]
`
`Ex.1057.010
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` 0x03 Login Command
` 0x04 Text Command
` 0x05 SCSI Data (for WRITE operation)
` 0x09 Ping Command (from initiator to target)
` 0x0a Map Command
`
` Valid opcodes for responses (sent by target to initiator) are:
` 0x40 NOP-In Message (from target to initiator)
` 0x41 SCSI Response (contains SCSI status and possibly sense
` information or other response information)
` 0x42 SCSI Task Management Response
` 0x43 Login Response
` 0x44 Text Response
` 0x45 SCSI Data (for READ operation)
` 0x46 Ready To Transfer (RTT - sent by target to initiator when
` it is ready to receive data from initiator)
` 0x47 Asynchronous Event (sent by target to initiator to indicate
` certain special conditions)
` 0x48 Opcode Not Understood
` 0x49 Ping Response (from target to initiator)
` 0x4a Map Response
`
`3.1.2. Length
`
` The Length field indicates the number of bytes, beyond the first 48
` bytes, that are being sent together with this message header. It is
` anticipated that most iSCSI messages and responses (not counting
` data transfer messages) will not need more than the 48 byte header,
` and hence the Length field will contain the value 0. It is
` expected that larger than 16 byte CDBs and parameter data will fol-
` low the header.
`
`3.1.3. LUN
`
` The LUN specifies the Logical Unit for which the command is tar-
` geted. If the command does not relate to a Logical Unit, this
` field is either ignored or may be used for some other purpose.
` According to [SAM2], a Logical Unit Number can take up to a 64-bit
` field that identifies the Logical Unit within a target device. The
` exact format of this field can be found in the [SAM2] document.
`
`3.1.4. Initiator Task Tag
`
` The initiator assigns a Task Id (or tag) to each SCSI task that it
` issues. (Recall that a task is a linked set of SCSI commands.)
` This Tag is an initiator-wide unique identifier that can be used to
` uniquely identify the Task.
`
`Satran, Smith, Sapuntzakis, Meth [Page 11]
`
`Ex.1057.011
`
`DELL
`
`

`

`
`iSCSI June 2000
`
`3.1.5. Opcode-specific fields
`
` These field have different meanings for different messages.
`
`Satran, Smith, Sapuntzakis, Meth [Page 12]
`
`Ex.1057.012
`
`DELL
`
`

`

`
`iSCSI June 2000
`
`3.2. SCSI Command
`
` Byte / 0 | 1 | 2 | 3 |
` / | | | |
` |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
` +---------------+---------------+---------------+---------------+
` 0| Opcode (0x01) |I I|R| Rsrvd |A| Rsvrd |ATTR | Reserved (0) |
` +---------------+---------------+---------------+---------------+
` 4| Length |
` +---------------+---------------+---------------+---------------+
` 8| Logical Unit Number (LUN) |
` + +
` 12| |
` +---------------+---------------+---------------+---------------+
` 16| Initiator Task Tag |
` +---------------+---------------+---------------+---------------+
` 20| Expected Data Transfer Length |
` +---------------+---------------+---------------+---------------+
` 24| CmdRN |
` +---------------+---------------+---------------+---------------+
` 28| ExpStatRN |
` +---------------+---------------+---------------+---------------+
` 32/ SCSI Command Descriptor Block (CDB) /
` +/ /
` +---------------+---------------+---------------+---------------+
` 48/ Additional Data (Command Dependent) /
` +/ /
` +---------------+---------------+---------------+---------------+
`
`3.2.1. Flags.
`
` The flags field for a SCSI Command consists of two bytes.
` Byte 1 - iSCSI flags
` b7-6 (I) Immediate Data from initiator to target (command
` parameters/write/control); this field indicates also how
` to interpret the length field:
` 00 - Immediate Data Length = Length; CDB Length = 16
` 01 - CDB Length = Length+16; Immediate Data Length = 0
` 10 - Immediate Data Length = Length 24 MSB; CDB Length = 16
` + Length(8 LSB)
` 11 - Immediate Data Length = Length 16 MSB; CDB Length = 16
` + Length(16 LSB)
` b5 (R) set when data is expected to flow from target to ini-
` tiator (read).
` b0-4 Reserved (should be 0)
` Byte 2 - SCSI flags
`
`Satran, Smith, Sapuntzakis, Meth [Page 13]
`
`Ex.1057.013
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` b7 (A) set to turn off Autosense for this command (see
` [SAM2]).
` b3-6 Reserved (should be 0)
` b0-2 used to indicate Task Attributes.
`
` Autosense refers to the automatic return of sense data to the ini-
` tiator in case a command did not complete successfully. If
` autosense is turned off, the initiator must explicitly request that
` sense data be sent to it after some command has completed with a
` CHECK CONDITION status.
`
`3.2.2. Task Attributes
`
` The Task Attribute field (ATTR) can have one of the following
` integer values (see [SAM2] for details):
`
` 0 Untagged
` 1 Simple
` 2 Ordered
` 3 Head of Queue
` 4 ACA
`
`3.2.3. Command Reference Number (CmdRN) enables ordered delivery
`
`3.2.4. ExpStatRN - Expected Status Reference Number
`
` Acknowledges status. Responses up to ExpStatRN -1 (mod 2**32) have
` been received. This number will also update the internal register.
` Values that do not appear as "increasing" will be ignored; this may
` be required when updates arrive out of order (they travel on dif-
` ferent TCP connections).
`
`3.2.5. Expected Data Transfer Length
`
` The Expected Data Transfer Length field states the number of bytes
` of data that the initiator expects will be sent for this (READ or
` WRITE) SCSI operation in SCSI Data packets. For a WRITE operation,
` the initiator uses this field to specify the number of bytes of
` data it expects to transfer for this operation in data packets (not
` counting data headers). For a READ operation, the initiator uses
` this field to specify the number of bytes of data it expects the
` target to transfer to the initiator (not counting data headers).
`
` If no data will be transferred in SCSI Data packets for this SCSI
` operation, this field should be set to 0.
`
`Satran, Smith, Sapuntzakis, Meth [Page 14]
`
`Ex.1057.014
`
`DELL
`
`

`

`
`iSCSI June 2000
`
` Upon completion of a data transfer, the target will inform the ini-
` tiator of how many bytes were actually processed (sent or received)
` by the target.
`
`3.2.6. SCSI Command Descriptor Block (CDB)
`
` There are 16 bytes in the CDB field, designed to accommodate the
` largest currently defined CDB. If, in the future, larger CDBs are
` allowed, the spill-over of the CDB may extend beyond the 48-byte
` header.
`
`3.2.7. Command-Data
`
` Some SCSI commands require additional parameter data to accompany
` the SCSI command. This data may be placed beyond the 48-byte boun-
` dary of the iSCSI header. Alternatively user data can be placed in
` the same PDU (in both cases we talk about immediate data).
`
`Satran, Smith, Sapuntzakis, Meth [Page 15]
`
`Ex.1057.015
`
`DELL
`
`

`

`
`iSCSI June 2000
`
`3.3. SCSI Response
`
` Byte / 0 | 1 | 2 | 3 |
` / | | | |
` |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
` +---------------+---------------+---------------+---------------+
` 0| Opcode (0x41) | Rsvd(0) |O|U| Reserved (0) |
` +---------------+---------------+---------------+---------------+
` 4| Length |
` +---------------+---------------+---------------+---------------+
` 8| Reserved (0) |
` + +
` 12| |
` +---------------+---------------+---------------+---------------+
` 16| Initiator Task Tag |
` +---------------+---------------+---------------+---------------+
` 20| Residual Count |
` +---------------+---------------+---------------+---------------+
` 24| StatRN |
` +---------------+---------------+---------------+---------------+
` 28| ExpCmdRN