iSCSI Operational Details

Cisco ''Storage Networking Protocol Fundamentals"

iSCSI Operational Details

This section provides an in-depth exploration of the operational details of iSCSI.  You are also encouraged to consult IETF RFC 3347 for an overview of the requirements that shaped the development of iSCSI.

1.iSCSI Addressing Scheme

iSCSI implements SCSI device names, port names, and port identifiers. Both device and port names are required by iSCSI. The SCSI device name is equivalent to the iSCSI node name. Three types of iSCSI node names are currently defined: iSCSI qualified name (IQN), extended unique identifier (EUI), and network address authority (NAA). Each iSCSI node name begins with a three-letter designator that identifies the type. RFC 3720 requires all iSCSI node names to be globally unique, but some node name types support locally administered names that are not globally unique. As with FC node names, global uniqueness can be guaranteed only by using globally administered names. To preserve global uniqueness, take care when moving iSCSI entities from one operating system image to another.

1.1 three types of  iSCSI node names

A.node name: IQN type

Currently, the IQN type is most prevalent . The IQN type provides globally unique iSCSI node names. The IQN format has four components: a type designator followed by a dot, a date code followed by a dot, the reverse domain name of the naming authority, and an optional device specific string that, if present, is prefixed by a colon. The type designator is "iqn". The date code indicates the year and month that the naming authority registered its domain name in the DNS. The reverse domain name identifies the naming authority. Sub-domains within the naming authority's primary domain are permitted; they enable delegation of naming tasks to departments, subsidiaries, and other subordinate organizations within the naming authority. The optional device specific string provides a unique iSCSI node name for each SCSI device . If the optional device specific string is not used, only one SCSI device can exist within the naming authority's namespace (as identified by the reverse domain name itself). Therefore, the optional device specific string is a practical requirement for real-world deployments. iSCSI node names of type IQN are variable in length up to a maximum of 223 characters . Examples include

iqn.1987-05.com.cisco:host1

iqn.1987-05.com.cisco.apac.singapore:ccm-host1

iqn.1987-05.com.cisco.erp:dr-host8-vpar1

B.node name:EUI type

The EUI type provides globally unique iSCSI node names assuming that the Extension Identifier sub-field within the EUI-64 string is not locally administered . The EUI format has two components: a type designator followed by a dot and a device specific string. The type designator is "eui". The device specific string is a valid IEEE EUI-64 string. Because the length of an EUI-64 string is eight bytes, and EUI-64 strings are expressed in hexadecimal, the length of an iSCSI node name of type EUI is fixed at 20 characters. For example

eui.02004567A425678D

C.node name: NAA type

The NAA type is based on the ANSI T11 NAA scheme. the ANSI T11 NAA scheme supports many formats. Some formats provide global uniqueness; others do not. In iSCSI, the NAA format has two components: a type designator followed by a dot and a device specific string. The type designator is "naa". The device specific string is a valid ANSI T11 NAA string. Because the length of ANSI T11 NAA strings can be either 8 or 16 bytes, iSCSI node names of type NAA are variable in length. ANSI T11 NAA strings are expressed in hexadecimal, so the length of an iSCSI node name of type NAA is either 20 or 36 characters. Examples include

naa.52004567BA64678D

naa.62004567BA64678D0123456789ABCDEF

D. iSCSI node alias

iSCSI allows the use of aliases for iSCSI node names . The purpose of an alias is to provide an easily recognizable, meaningful tag that can be displayed in tools, utilities, and other user interfaces. Although IQNs are text-based and somewhat intuitive, the device-specific portion might need to be very long and even cryptic to adequately ensure a scalable nomenclature in large iSCSI environments. Likewise, EUI and NAA formatted node names can be very difficult for humans to interpret. Aliases solve this problem by associating a human-friendly tag with each iSCSI node name. Aliases are used only by humans. Aliases might not be used for authentication or authorization. Aliases are variable in length up to a maximum of 255 characters.

 

1.2 iSCSI port name and port identifier,session identifier

SCSI port names and identifiers are handled somewhat differently in iSCSI as compared to other SAM Transport Protocols . iSCSI uses a single string as both the port name and port identifier. The string is globally unique, and so the string positively identifies each port within the context of iSCSI. This complies with the defined SAM functionality for port names. However, the string does not contain any resolvable address to facilitate packet forwarding. Thus, iSCSI requires a mapping of its port identifiers to other port types that can facilitate packet forwarding. For this purpose, iSCSI employs the concept of a network portal. Within an iSCSI device, an Ethernet (or other) interface configured with an IP address is called a network portal. Network portals facilitate packet forwarding, while iSCSI port identifiers serve as session endpoint identifiers . Within an initiator device, each network portal is identified by its IP address. Within a target device, each network portal is identified by its IP address and listening TCP port (its socket). Network portals that share compatible operating characteristics may form a portal group . Within a target device, each portal group is assigned a target portal group tag ( TPGT).

SCSI ports are implemented differently for iSCSI initiators versus iSCSI targets. Upon resolution of a target iSCSI node name to one or more sockets, an iSCSI initiator logs into the target. After login completes, a SCSI port is dynamically created within the initiator. In response, the iSCSI port name and identifier are created by concatenating the initiator's iSCSI node name, the letter "i" (indicating this port is contained within an initiator device) and the initiator session identifier ( ISID). The ISID is 6 bytes long and is expressed in hexadecimal. These three fields are comma-separated. For example

iqn.1987-05.com.cisco:host1, i,0x00023d000002

The order of these events might seem counter-intuitive, but recall that iSCSI port identifiers do not facilitate packet forwarding; network portals do. So, iSCSI port identifiers do not need to exist before the iSCSI login. Essentially, iSCSI login signals the need for a SCSI port, which is subsequently created and then used by the SCSI Application Layer (SAL).

that SAM port names must never change. One might think that iSCSI breaks this rule, because initiator port names seem to change regularly. iSCSI creates and destroys port names regularly, but never changes port names. iSCSI generates each new port name in response to the creation of a new SCSI port. Upon termination of an iSCSI session, the associated initiator port is destroyed. Because the iSCSI port name does not change during the lifetime of its associated SCSI port, iSCSI complies with the SAM persistence requirement for port names.

In a target device, SCSI ports are also created dynamically in response to login requests. The target port name and identifier are created by concatenating the target's iSCSI node name, the letter "t" (indicating this port is contained within a target device) and the TPGT. The target node infers the appropriate TPGT from the IP address at which the login request is received . The TPGT is 2 bytes long and is expressed in hexadecimal. These three fields are comma-separated. For example

iqn.1987-05.com.cisco:array1, t,0x4097

All network portals within a target portal group share the same iSCSI port identifier and represent the same SCSI port. Because iSCSI target port names and identifiers are based on TPGTs, and because a network portal may operate independently (not part of a portal group), a TPGT must be assigned to each network portal that is not part of a portal group. Thus, a network portal that operates independently forms a portal group of one.

Some background information helps us fully understand ISID and TPGT usage. According to the SAM, the relationship between a SCSI initiator port and a SCSI target port is known as the initiator-target nexus ( I_T nexus) . The I_T nexus concept underpins all session-oriented constructs in all modern storage networking technologies . At any point in time, only one I_T nexus can exist between a pair of SCSI ports. According to the SAM, an I_T nexus is identified by the conjunction of the initiator port identifier and the target port identifier. The SAM I_T nexus is equivalent to the iSCSI session. Thus, only one iSCSI session can exist between an iSCSI initiator port identifier and an iSCSI target port identifier at any point in time.

iSCSI initiators adhere to this rule by incorporating the ISID into the iSCSI port identifier. Each new session is assigned a new ISID, which becomes part of the iSCSI port identifier of the newly created SCSI port, which becomes part of the I_T nexus. Each ISID is unique within the context of an initiator-target-TPGT triplet. If an initiator has an active session with a given target device and establishes another session with the same target device via a different target portal group, the initiator may reuse any active ISID. In this case, the new I_T nexus is formed between a unique pair of iSCSI port identifiers because the target port identifier includes the TPGT. Likewise, any active ISID may be reused for a new session with a new target device. Multiple iSCSI sessions may exist simultaneously between an initiator device and a target device as long as each session terminates on a different iSCSI port identifier (representing a different SCSI port) on at least one end of the session. Initiators accomplish this by connecting to a different target portal group or assigning a new ISID. Note that RFC 3720 encourages the reuse of ISIDs in an effort to promote initiator SCSI port persistence for the benefit of applications, and to facilitate target recognition of initiator SCSI ports in multipath environments.

Note

RFC 3720 officially defines the I_T nexus identifier as the concatenation of the iSCSI initiator port identifier and the iSCSI target port identifier (initiator node name + "i" + ISID + target node name + "t" + TPGT). This complies with the SAM definition of I_T nexus identifier. However, RFC 3720 also defines a session identifier ( SSID) that can be used to reference an iSCSI session. The SSID is defined as the concatenation of the ISID and the TPGT. Because the SSID is ambiguous, it has meaning only in the context of a given initiator-target pair.

iSCSI may be implemented as multiple hardware and software components within a single network entity. As such, coordination of ISID generation in an RFC-compliant manner across all involved components can be challenging. For this reason, RFC 3720 requires a single component to be responsible for the coordination of all ISID generation activity. To facilitate this rule, the ISID format is flexible. It supports a namespace hierarchy that enables coordinated delegation of ISID generation authority to various independent components within the initiator entity. Figure 8-1 illustrates the general ISID format.

Figure 8-1. General iSCSI ISID Format

A brief description of each field follows:

• T This is 2 bits long and indicates the format of the ISID. Though not explicitly stated in RFC 3720, T presumably stands for type.
• A This is 6 bits long and may be concatenated with the B field. Otherwise, the A field is reserved.
• B This is 16 bits long and may be concatenated with the A field or the C field. Otherwise, the B field is reserved.
• C This is 8 bits long and may be concatenated with the B field or the D field. Otherwise, the C field is reserved.
• D This is 16 bits long and may be concatenated with the C field or used as an independent field. Otherwise, the D field is reserved.

Table 8-1 summarizes the possible values of T and the associated field descriptions.

Table 8-1. ISID Format Descriptions

T Value	ISID Format	Field Descriptions
00b	OUI	A & B form a 22-bit field that contains the OUI of the vendor of the component that generates the ISID. The I/G and U/L bits are omitted. C & D form a 24-bit qualifier field that contains a value generated by the component.
01b	EN	A is reserved. B & C form a 24-bit field that contains the IANA enterprise number (EN) of the vendor of the component that generates the ISID. D is a 16-bit qualifier field that contains a value generated by the component.
10b	Random	A is reserved. B & C form a 24-bit field that contains a value that is randomly generated by the component responsible for ISID coordination. A unique value is assigned to each subordinate component that generates ISIDs . D is a 16-bit qualifier field that contains a value generated by subordinate components.
11b	Reserved	All fields are reserved. This T value is currently not used.

The target also assigns a session identifier to each new session. This is known as the target session identifying handle (TSIH). During login for a new session, the initiator uses a TSIH value of zero . The target generates the TSIH value during login and sends the new value to the initiator in the final login response. In all subsequent packets, the assigned TSIH is used by the initiator to enable the target to associate received packets with the correct session. The TSIH is two bytes long, but the format of the TSIH is not defined in RFC 3720. Each target determines its own TSIH format. For more information about iSCSI device names, port names, port identifiers, and session identifiers, readers are encouraged to consult IETF RFCs 3720, 3721, 3722, and 3980, and ANSI T10 SAM-3.

1.3.iSCSI Name Assignment and Resolution

iSCSI is designed to operate with a single node name per operating system image. iSCSI node names can be preset in iSCSI hardware at time of manufacture, dynamically created by iSCSI software at time of installation, or manually assigned by the storage network administrator during initial configuration. If the node name is preset in iSCSI hardware at time of manufacture, RFC 3720 mandates the storage network administrator must be provided a way to change the node name. As previously discussed, iSCSI port names are dynamically assigned by the iSCSI hardware or software upon creation of a SCSI port.

iSCSI name resolution is tied to iSCSI name discovery. Because three methods of target discovery exist， three methods of name resolution exist: manual, semi-manual, and automated.

 A.name resolution：manual

A manually configured iSCSI initiator node is given the iSCSI node names of all targets to which access is permitted. The socket(s) associated with each target node also must be manually configured. In this environment, name resolution occurs within the initiator node and does not involve any network service.

B.name resolution：semi-manual

A semi-manually configured iSCSI initiator node is given the socket(s) to which the SendTargets command should be sent. The SendTargets response contains the TPGT for the network portal at which the request was received . The SendTargets response also contains the iSCSI node name of each target accessible via that portal group. This constitutes reverse name resolution (that is, address-to-name resolution) . The SendTargets response also may contain additional socket and TPGT information for each target node name. This constitutes normal name resolution (that is, name-to-address resolution).

C.name reaolution:automate

When using SLP with a DA, each target entity registers its target nodes in the DA store. Each target node is registered independently as a service URL containing the iSCSI node name, IP address, TCP port, and TPGT. If a target node is accessible via multiple network portals, a service URL is registered for each network portal. Upon booting, an initiator queries the DA to discover accessible targets. The DA response contains the service URL(s) to which access has been administratively granted (based on scope membership). When using SLP without a DA, each SA entity responds to queries it receives. The SA response contains all the service URLs implemented within that target entity to which the initiator has been administratively granted access (based on scope membership). With or without a DA, name resolution is inherent to the discovery process because the service URL contains the iSCSI node name and all relevant network portal information. SLP does not support RSCN functionality, so initiators must periodically send update requests to the DA or to each SA to discover any new targets that come online after initial discovery.

The iSNS model is very similar to the SLP model. When using iSNS, clients (target and initiator entities) must register with the iSNS server before they can query the iSNS server. Each target entity registers its target node names, network portal information (including IP addresses and TCP port numbers), and TPGT information. Initiator entities query the iSNS server and receive a response containing the iSCSI node name of each target node to which access has been administratively granted (based on Discovery Domain membership). The response also contains the relevant network portal and TPGT information. Thus, name resolution is inherent to the discovery process. iSNS also has the advantage of RSCN support. Clients do not need to periodically query for current status of other devices. Instead, clients may register to receive SCN messages. For more information about iSCSI name resolution, readers are encouraged to consult IETF RFCs 2608, 3720, 3721, 4018, and 4171.

1.4.iSCSI Address Assignment and Resolution

As previously discussed, iSCSI port identifiers are dynamically assigned by the iSCSI hardware or software upon creation of a SCSI port. However, iSCSI port identifiers are not addresses per se. To facilitate forwarding of iSCSI packets, IP addresses are required. IP address assignment is handled in the customary manner (manually or via DHCP) . No special addressing requirements are mandated by iSCSI, and no special addressing procedures are implemented by network entities that host iSCSI processes. After an IP address is assigned to at least one network portal within an iSCSI device, iSCSI can begin communication. Likewise, address resolution is accomplished via the customary mechanisms. For example, IP addresses are resolved to Ethernet address via ARP. IP address assignment and resolution are transparent to iSCSI.

2.iSCSI Session Types, Phases, and Stages

iSCSI implements two types of session: discovery and normal. Both session types operate on TCP. Each discovery session uses a single TCP connection. Each normal session can use multiple TCP connections for load balancing and improved fault tolerance. A discovery session is used to discover iSCSI target node names and network portal information via the SendTargets command. A normal session is used for all other purposes. Discovery sessions are optional, and normal sessions are mandatory . We discussed discovery sessions in Chapter 3, so this section focuses on normal sessions.

The login phase always occurs first and is composed of two stages: security parameter negotiation and operational parameter negotiation . Each stage is optional, but at least one of the two stages must occur. If the security parameter negotiation stage occurs, it must occur first. Authentication is optional. If authentication is implemented, it occurs during the security parameter negotiation stage. Therefore, the security parameter negotiation stage must occur if authentication is implemented. Currently, authentication is the only security parameter negotiated during this stage.

Although the operational parameter negotiation stage is optional according to RFC 3720, it is a practical requirement for real-world deployments . Each initiator and target device must support the same operational parameters to communicate successfully. It is possible for the default settings of every iSCSI device to match, but it is not probable. So, negotiable parameters must be configured manually or autonegotiated. Manually setting all negotiable parameters on every iSCSI device can be operationally burdensome. Thus, the operational parameter negotiation stage is implemented by all iSCSI devices currently on the market. Support for unsolicited writes, the maximum burst length and various other parameters are negotiated during this stage.

Following the login phase, the iSCSI session transitions to the full feature phase. During the full feature phase of a normal session, initiators can issue iSCSI commands as well as send SCSI commands and data . Additionally, certain iSCSI operational parameters can be re-negotiated during the full feature phase. When all SCSI operations are complete, a normal iSCSI session can be gracefully terminated via the iSCSI Logout command. If a normal session is terminated unexpectedly, procedures are defined to clean up the session before reinstating the session. Session cleanup prevents processing of commands and responses that might have been delayed in transit, thus avoiding data corruption . Procedures are also defined to re-establish a session that has been terminated unexpectedly, so SCSI processing can continue from the point of abnormal termination . After all normal sessions have been terminated gracefully, the discovery session (if extant) can be terminated gracefully via the iSCSI Logout command. For more information about iSCSI session types, phases, and stages, readers are encouraged to consult IETF RFC 3720. Figure 8-2 illustrates the flow of iSCSI sessions, phases, and stages.

Figure 8-2. iSCSI Session Flow

[View full size image]

3.iSCSI Data Transfer Optimizations

3.1 SCSI  I/O(read and write) operation

iSCSI handles data transfer very flexibly. To understand the data transfer options provided by iSCSI, some background information about SCSI I/O operations is required. SCSI defines the direction of data transfer from the perspective of the initiator. Data transfer from initiator to target (write command) is considered outbound, and data transfer from target to initiator (read command) is considered inbound. The basic procedure for a SCSI read operation involves three steps . First, the initiator sends a SCSI read command to the target. Next, the target sends the requested data to the initiator. Finally, the target sends a SCSI status indicator to the initiator. The read command specifies the starting block address and the number of contiguous blocks to transfer. If the data being retrieved by the application client is fragmented on the storage medium (that is, stored in non-contiguous blocks), then multiple read commands must be issued (one per set of contiguous blocks). For each set of contiguous blocks, the initiator may issue more than one read command if the total data in the set of contiguous blocks exceeds the initiator's available receive buffer resources. This eliminates the need for a flow-control mechanism for read commands. A target always knows it can send the entire requested data set because an initiator never requests more data than it is prepared to receive. When multiple commands are issued to satisfy a single application client request, the commands may be linked together as a single SCSI task . Such commands are called SCSI linked commands.

The basic procedure for a SCSI write operation involves four steps. First, the initiator sends a SCSI write command to the target. Next, the target sends an indication that it is ready to receive the data. Next, the initiator sends the data. Finally, the target sends a SCSI status indicator to the initiator. The write command specifies the starting block address and the number of contiguous blocks that will be transferred by this command. If the data being stored by the application client exceeds the largest contiguous set of available blocks on the medium, multiple write commands must be issued (one per set of contiguous blocks). The commands may be linked as a single SCSI task. A key difference between read and write operations is the initiator's knowledge of available receive buffer space . When writing, the initiator does not know how much buffer space is currently available in the target to receive the data. So, the target must inform the initiator when the target is ready to receive data (that is, when receive buffers are available). The target must also indicate how much data to transfer. In other words, a flow-control mechanism is required for write operations. The SAM delegates responsibility for this flow-control mechanism to each SCSI Transport Protocol.

 

3.2 iSCSI optimize data transfer

 

In iSCSI parlance, the data transfer steps are called phases (not to be confused with phases of an iSCSI session) . iSCSI enables optimization of data transfer through phase-collapse. Targets may include SCSI status as part of the final data PDU for read commands. This does not eliminate any round-trips across the network, but it does reduce the total number of PDUs required to complete the read operation. Likewise, initiators may include data with write command PDUs. This can be done in two ways. Data may be included as part of the write command PDU. This is known as immediate data. Alternately, data may be sent in one or more data PDUs immediately following a write command PDU without waiting for the target to indicate its readiness to receive data. This is known as unsolicited data. In both cases, one round-trip is eliminated across the network, which reduces the total time to completion for the write operation. In the case of immediate data, one data PDU is also eliminated. The initiator must negotiate support for immediate data and unsolicited data during login . Each feature is negotiated separately. If the target supports phase-collapse for write commands, the target informs the initiator (during login) how much data may be sent using each feature . Both features may be supported simultaneously. Collectively, immediate data and unsolicited data are called first burst data. First burst data may be sent only once per write command (the first sequence of PDUs) . For more information about iSCSI phase-collapse, readers are encouraged to consult IETF RFC 3720.

Note:

In the generic sense, immediate data is actually a subset of unsolicited data. Unsolicited data generically refers to any data sent to the target without first receiving an indication from the target that the target is ready for the data transfer. By that generic definition, immediate data qualifies as unsolicited data. However, the term unsolicited data has specific meaning in the context of iSCSI. Note that data sent in response to an indication of receiver readiness is called solicited data.

 

 

 

4.iSCSI PDU Formats

 

iSCSI uses one general PDU format for many purposes. The specific format of an iSCSI PDU is determined by the type of PDU. RFC 3720 defines numerous PDU types to facilitate communication between initiators and targets. Of these, the primary PDU types include login request, login response, SCSI command, SCSI response, data-out, data-in, ready to transfer (R2T), selective negative acknowledgment (SNACK) request, task management function (TMF) request, TMF response, and reject. All iSCSI PDUs begin with a basic header segment (BHS). The BHS may be followed by one or more additional header segments (AHS), a header-digest, a data segment, or a data-digest. The data-digest may be present only if the data segment is present. iSCSI PDUs are word-oriented, and an iSCSI word is 4 bytes. All iSCSI PDU segments and digests that do not end on a word boundary must be padded to the nearest word boundary. RFC 3720 encourages, but does not require, the value of 0 for all padding bits. Figure 8-3 illustrates the general iSCSI PDU format.

Figure 8-3. General iSCSI PDU Format

[View full size image]

A brief description of each field follows:

• BHS This is 48 bytes long. It is the only mandatory field. The BHS field indicates the type of PDU and contains most of the control information used by iSCSI.
• Optional AHS Each is variable in length. The purpose of the AHS field is to provide protocol extensibility. Currently, only two AHS types are defined: extended command descriptor block (CDB) and expected bidirectional read data length.
• Optional Header-Digest Each is variable in length as determined by the kind of digest used. This field provides additional header integrity beyond that of the IP and TCP checksums. During login, each initiator-target pair negotiates whether a header digest will be used and, if so, what kind. Separating the header digest from the data digest improves the operational efficiency of iSCSI gateways that modify header fields.
• Optional Data This is variable in length. It contains PDU-specific data.
• Optional Data-Digest This is variable in length as determined by the kind of digest used. This field provides additional data integrity beyond that of the IP and TCP checksums. During login, each initiator-target pair negotiates whether a data digest will be used and, if so, what kind.

The remainder of this section focuses on the BHS because the two defined AHSs are less commonly used. Details of the BHS are provided for each of the primary iSCSI PDU types. Figure 8-4 illustrates the general format of the iSCSI BHS. All fields marked with "." are reserved.

Figure 8-4. iSCSI BHS Format

[View full size image]

A brief description of each field follows:

• Reserved This is 1 bit.
• I This is 1 bit. I stands for immediate delivery. When an initiator sends an iSCSI command or SCSI command that should be processed immediately, the I bit is set to 1. When this bit is set to 1, the command is called an immediate command. This should not be confused with immediate data (phase-collapse). When this bit is set to 0, the command is called a non-immediate command.
• Opcode This is 6 bits long. The Opcode field contains an operation code that indicates the type of PDU. Opcodes are defined as initiator opcodes (transmitted only by initiators) and target opcodes (transmitted only by targets). RFC 3720 defines 18 opcodes (see Table 8-2).
• F This is 1 bit. F stands for final PDU. When this bit is set to 1, the PDU is the final (or only) PDU in a sequence of PDUs. When this bit is set to 0, the PDU is followed by one or more PDUs in the same sequence. The F bit is redefined by some PDU types.
• Opcode-specific Sub-fields These are 23 bits long. The format and use of all Opcode-specific sub-fields are determined by the value in the Opcode field.
• TotalAHSLength This is 8 bits long. It indicates the total length of all AHS fields. This field is needed because the AHS fields are variable in number and length. The value is expressed in 4-byte words and includes padding bytes (if any exist). If no AHS fields are present, this field is set to 0.
• DataSegmentLength This is 24 bits long. It indicates the total length of the Data segment. This field is needed because the Data segment is variable in length. The value is expressed in bytes and does not include padding bytes (if any exist). If no Data segment is present, this field is set to 0.
• LUN field and the Opcode-specific Sub-fields These are 64 bits (8 bytes) long. They contain the destination LUN if the Opcode field contains a value that is relevant to a specific LUN (such as a SCSI command). When used as a LUN field, the format complies with the SAM LUN format. When used as Opcode-specific sub-fields, the format and use of the sub-fields are opcode-specific.
• Initiator Task Tag (ITT) This is 32 bits long. It contains a tag assigned by the initiator. An ITT is assigned to each iSCSI task. Likewise, an ITT is assigned to each SCSI task. A SCSI task can represent a single SCSI command or multiple linked commands. Each SCSI command can have many SCSI activities associated with it. A SCSI task encompasses all activities associated with a SCSI command or multiple linked commands. Likewise, an ITT that represents a SCSI task also encompasses all associated activities of the SCSI command(s). An ITT value is unique only within the context of the current session. The iSCSI ITT is similar in function to the FC fully qualified exchange identifier (FQXID).
• Opcode-specific Sub-fields These are 224 bits (28 bytes) long. The format and use of the sub-fields are opcode-specific.

Table 8-2 summarizes the iSCSI opcodes that are currently defined in RFC 3720. All opcodes excluded from Table 8-2 are reserved.

Table 8-2. iSCSI Operation Codes

Category	Value	Description
Initiator	0x00	NOP-out
Initiator	0x01	SCSI command
Initiator	0x02	SCSI task management request
Initiator	0x03	Login request
Initiator	0x04	Text request
Initiator	0x05	SCSI data-out
Initiator	0x06	Logout request
Initiator	0x10	SNACK request
Initiator	0x1C-0x1E	Vendor-specific codes
Target	0x20	NOP-in
Target	0x21	SCSI response
Target	0x22	SCSI task management response
Target	0x23	Login response
Target	0x24	Text response
Target	0x25	SCSI data-in
Target	0x26	Logout response
Target	0x31	Ready to transfer (R2T)
Target	0x32	Asynchronous message
Target	0x3C-0x3E	Vendor-specific codes
Target	0x3F	Reject

The first login request of a new session is called the leading login request . The first TCP connection of a new session is called the leading connection . Figure 8-5 illustrates the iSCSI BHS of a Login Request PDU. Login parameters are encapsulated in the Data segment (not shown) as text key-value pairs. All fields marked with "." are reserved.

Figure 8-5. iSCSI Login Request BHS Format

[View full size image]

A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:

• Reserved This is 1 bit.
• I This is always set to 1.
• Opcode This is 6 bits long. It is set to 0x03.
• T This is the F bit redefined as the T bit. T stands for transit. This bit is set to 1 when the initiator is ready to change to the next login stage.
• C This is 1 bit. It indicates whether the set of text keys in this PDU is complete. C stands for continue. When the set of text keys is too large for a single PDU, the C bit is set to 1, and another PDU follows containing more text keys. When all text keys have been transmitted, the C bit is set to 0. When the C bit is set to 1, the T bit must be set to 0.
• Reserved This is 2 bits long.
• CSG This is 2 bits long. It indicates the current stage of the login procedure. The value 0 indicates the security parameter negotiation stage. The value 1 indicates the operational parameter negotiation stage. The value 2 is reserved. The value 3 indicates the full feature phase. These values also used are by the NSG field.
• NSG This is 2 bits long. It indicates the next stage of the login procedure.
• Version-Max This is 8 bits long. It indicates the highest supported version of the iSCSI protocol. Only one version of the iSCSI protocol is currently defined. The current version is 0x00.
• Version-Min This is 8 bits long. It indicates the lowest supported version of the iSCSI protocol.
• TotalAHSLength This is 8 bits long.
• DataSegmentLength This is 24 bits long.
• ISID This is 48 bits (6 bytes) long. For a new session, this value is unique within the context of the initiator-target-TPGT triplet. For a new connection within an existing session, this field indicates the session to which the new connection should be added.
• TSIH This is 16 bits long. For a new session, the initiator uses the value 0. Upon successful completion of the login procedure, the target provides the TSIH value to the initiator in the final Login Response PDU. For a new connection within an existing session, the value previously assigned to the session by the target must be provided by the initiator in the first and all subsequent Login Request PDUs.
• ITT This is 32 bits long.
• Connection Identifier (CID) This is 16 bits long. The initiator assigns a CID to each TCP connection. The CID is unique only within the context of the session to which the connection belongs. Each TCP connection may be used by only a single session.
• Reserved This is 16 bits long.
• Command Sequence Number (CmdSN) This is 32 bits long. The initiator assigns a unique sequence number to each non-immediate SCSI command issued within a session. This field enables in-order delivery of all non-immediate commands within a session even when multiple TCP connections are used. For a leading login request, the value of this field is arbitrarily selected by the initiator. The same value is used until login successfully completes. The same value is then used for the first non-immediatenon-immediate SCSI Command PDU. The CmdSN counter is then incremented by one for each subsequent new non-immediate command, regardless of which TCP connection is used. If the login request is for a new connection within an existing session, the value of this field must reflect the current CmdSN of that session. The first non-immediate SCSI Command PDU sent on the new TCP connection also must use the current CmdSN value, which can continue to increment while login processing occurs on the new connection. Both initiator and target track this counter. The iSCSI CmdSN is similar in function to the FCP command reference number (CRN).
• ExpStatSN or Reserved This is 32 bits long. It may contain the iSCSI Expected Status Sequence Number. Except during login, the initiator uses the ExpStatSN field to acknowledge receipt of SCSI Response PDUs. The target assigns a status sequence number (StatSN) to each SCSI Response PDU. While the CmdSN is session-wide, the StatSN is unique only within the context of a TCP connection. For a leading login request, this field is reserved. If the login request is for a new connection within an existing session, this field is reserved. If the login request is for recovery of a lost connection, this field contains the last value of ExpStatSN from the failed connection. If multiple Login Request PDUs are sent during recovery, this field is incremented by one for each Login Response PDU received. Thus, during login, this field is either not used or is used to acknowledge receipt of Login Response PDUs.
• Reserved This is 128 bits (16 bytes) long.

Each Login Request PDU or sequence of Login Request PDUs precipitates a Login Response PDU or sequence of Login Response PDUs. Figure 8-6 illustrates the iSCSI BHS of a Login Response PDU. Login parameters are encapsulated in the Data segment (not shown) as text key-value pairs. All fields marked with "." are reserved.

Figure 8-6. iSCSI Login Response BHS Format

[View full size image]

A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:

• Reserved This is 1 bit.
• Reserved This is the 1 bit redefined as Reserved.
• Opcode This is 6 bits long. It is set to 0x23.
• T bit This is the F bit redefined as the T bit. This bit is set to 1 when the target is ready to change to the next login stage. The target may set this bit to 1 only if the most recently received Login Request PDU had a T bit value of 1.
• C This is 1 bit.
• Reserved This is 2 bits long.
• CSG This is 2 bits long.
• NSG This is 2 bits long.
• Version-Max This is 8 bits long.
• Version-Active This is 8 bits long. It indicates the highest iSCSI protocol version that both the target and the initiator have in common. If no version is common to both target and initiator, the target rejects the login request, and this field reverts to Version-Min.
• TotalAHSLength This is 8 bits long.
• DataSegmentLength This is 24 bits long.
• ISID This is 48 bits (6 bytes) long.
• TSIH This is 16 bits long.
• ITT This is 32 bits long.
• Reserved This is 32 bits long.
• Status Sequence Number (StatSN) This is 32 bits long. iSCSI assigns a sequence number to each new Login Response PDU and each new SCSI Response PDU sent within a session. This field enables recovery of lost status and Login Response PDUs. When multiple TCP connections are used, the value of StatSN is maintained independently for each TCP connection. Mandatory support for connection allegiance makes this possible. For the first login response sent on each TCP connection, the value of this field is arbitrarily selected by the target. Each time a new Login Response PDU or a new SCSI Response PDU is transmitted, the StatSN of the associated TCP connection is incremented by one. A retransmitted SCSI Response PDU carries the same StatSN as the original PDU. This field is valid only when the Status-Class field is set to 0.
• Expected Command Sequence Number (ExpCmdSN) This is 32 bits long. This field enables the target to acknowledge receipt of commands. Both initiator and target track this counter. The target calculates this value by adding 1 to the highest CmdSN received in a valid PDU. The initiator does not calculate this value. Instead, the initiator uses the value received most recently from the target. This field is valid only when the Status-Class field is set to 0.
• Maximum Command Sequence Number (MaxCmdSN) This is 32 bits long. Whereas lower layers of the OSI model implement flow control at the granularity of a byte or a frame or packet, this field enables flow control at the granularity of a SCSI command. The maximum number of SCSI commands that the target can queue is determined by the resources (such as memory) within the target. This field allows the target to inform the initiator of available resources at a given point in time. Both initiator and target track this counter. The target increments its MaxCmdSN counter by 1 each time it transmits a SCSI Response PDU. The initiator does not calculate this value. Instead, the initiator uses the value received most recently from the target. The maximum number of commands the target can accept from the initiator at a given point in time is calculated as the current value of the target's MaxCmdSN counter minus the current value of the target's CmdSN counter. When the target's CmdSN counter equals its MaxCmdSN counter, the target cannot accept new commands within this session. This field is valid only when the Status-Class field is set to 0.
• Status-Class This is 8 bits long. It indicates the status of the most recently received Login Request PDU. A value of 0 indicates that the request was understood and processed properly. A value of 1 indicates that the initiator is being redirected. Redirection usually indicates the target IP address has changed; a text key-value pair must be included in the Data segment to indicate the new IP address. A value of 2 indicates that the target has detected an initiator error. The login procedure should be aborted, and a new login phase should be initiated if the initiator still requires access to the target. A value of 3 indicates that the target has experienced an internal error. The initiator may retry the request without aborting the login procedure. All other values are currently undefined but not explicitly reserved.
• Status-Detail This is 8 bits long. It provides more detail within each category of Status-Class. This field is meant to be used by sophisticated iSCSI initiator implementations and may be ignored by simple iSCSI initiator implementations.
• Reserved This is 80 bits long.

Following login, the initiator may send SCSI commands to the target. Figure 8-7 illustrates the iSCSI BHS of a SCSI Command PDU. All fields marked with "." are reserved.

Figure 8-7. iSCSI SCSI Command BHS Format

[View full size image]

A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:

• Reserved This is 1 bit.
• I This is 1 bit.
• Opcode This is 6 bits long. It is set to 0x01.
• F This is 1 bit.
• R This is 1 bit. It indicates a read command when set to 1. For bidirectional commands, both the R and W bits are set to 1.
• W This is 1 bit. It indicates a write command when set to 1. For bidirectional commands, both the R and W bits are set to 1.
• Reserved This is 2 bits long.
• ATTR This is 3 bits long. It indicates the SCSI Task Attribute. A value of 0 indicates an untagged task. A value of 1 indicates a simple task. A value of 2 indicates an ordered task. A value of 3 indicates a Head Of Queue task. A value of 4 indicates an Auto Contingent Allegiance (ACA) task. All other values are reserved. For more information about SCSI Task Attributes, see the ANSI T10 SAM-3 specification.
• Reserved This is 16 bits long.
• TotalAHSLength This is 8 bits long.
• DataSegmentLength This is 24 bits long.
• LUN This is 64 bits (8 bytes) long.
• ITT This is 32 bits long.
• Expected Data Transfer Length This is 32 bits long. It indicates the total amount of data expected to be transferred unidirectionally by this command. This field is expressed in bytes. When the data transfer is bidirectional, this field represents the write data, and the Expected Bidirectional Read Data Length AHS must follow the BHS. This field is set to 0 for certain commands that do not transfer data. This field represents an estimate. After all data is transferred, the target informs the initiator of how much data was actually transferred.
• CmdSN This is 32 bits long. It contains the current value of the CmdSN counter. The CmdSN counter is incremented by 1 immediately following transmission of a new non-immediate command. Thus, the counter represents the number of the next non-immediate command to be sent. The only exception is when an immediate command is transmitted. For an immediate command, the CmdSN field contains the current value of the CmdSN counter, but the counter is not incremented after transmission of the immediate command. Thus, the next non-immediate command to be transmitted carries the same CmdSN as the preceding immediate command. The CmdSN counter is incremented by 1 immediately following transmission of the first non-immediate command to follow an immediate command. A retransmitted SCSI Command PDU carries the same CmdSN as the original PDU. Note that a retransmitted SCSI Command PDU also carries the same ITT as the original PDU.
• ExpStatSN This is 32 bits long.
• SCSI CDB This is 128 bits (16 bytes) long. Multiple SCSI CDB formats are defined by ANSI. SCSI CDBs are variable in length up to a maximum of 260 bytes, but the most common CDB formats are 16 bytes long or less. Thus, the most common CDB formats can fit into this field. When a CDB shorter than 16 bytes is sent, this field is padded with zeros. When a CDB longer than 16 bytes is sent, the BHS must be followed by an Extended CDB AHS containing the remainder of the CDB. All CDBs longer than 16 bytes must end on a 4-byte word boundary, so the Extended CDB AHS does not require padding.

The final result of each SCSI command is a SCSI status indicator delivered in a SCSI Response PDU. The SCSI Response PDU also conveys iSCSI status for protocol operations. Figure 8-8 illustrates the iSCSI BHS of a SCSI Response PDU. All fields marked with "." are reserved.

Figure 8-8. iSCSI SCSI Response BHS Format

[View full size image]

A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:

• Reserved This is 1 bit.
• Reserved This is the 1 bit redefined as Reserved.
• Opcode This is 6 bits long and is set to 0x21.
• F bit This is always set to 1.
• Reserved This is 2 bits long.
• o This is 1 bit. The o stands for overflow. When a bidirectional command generates more read data than expected by the initiator, this bit is set to 1. This condition is known as a Bidirectional Read Residual Overflow. This bit is not used for unidirectional commands. This bit is valid only if the Response field is set to 0x00.
• u This is 1 bit. The u stands for underflow. When a bidirectional command generates less read data than expected by the initiator, this bit is set to 1. This condition is known as a Bidirectional Read Residual Underflow. This bit is not used for unidirectional commands. This bit is valid only if the Response field is set to 0x00.
• O This is 1 bit. The O stands for overflow. When a bidirectional command generates more write data than expected by the initiator, this bit is set to 1. This condition is known as a Bidirectional Write Residual Overflow. When a unidirectional read command generates more data than expected by the initiator, this bit is set to 1. When a unidirectional write command generates more data than expected by the initiator, this bit is set to 1. In both unidirectional cases, this condition is known as a Residual Overflow. This bit is valid only if the Response field is set to 0x00.
• U This is 1 bit. The U stands for underflow. When a bidirectional command generates less write data than expected by the initiator, this bit is set to 1. This condition is known as a Bidirectional Write Residual Underflow . When a unidirectional read command generates less data than expected by the initiator, this bit is set to 1. When a unidirectional write command generates less data than expected by the initiator, this bit is set to 1. In both unidirectional cases, this condition is known as a Residual Underflow. This bit is valid only if the Response field is set to 0x00.
• Reserved This is 1 bit.
• Response This is 8 bits long and contains a code that indicates the presence or absence of iSCSI protocol errors. The iSCSI response code is to the SCSI service delivery subsystem what the SCSI status code is to SAL. An iSCSI response code of 0x00 is known as Command Completed at Target. It indicates the target has completed processing the command from the iSCSI perspective. This iSCSI response code is roughly equivalent to a SCSI service response of LINKED COMMAND COMPLETE or TASK COMPLETE. This iSCSI response code is also roughly equivalent to an FCP_RSP_LEN_VALID bit set to zero. An iSCSI response code of 0x00 conveys iSCSI success but does not imply SCSI success. An iSCSI response code of 0x01 is known as Target Failure . It indicates failure to process the command. This iSCSI response code is roughly equivalent to a SCSI service response of SERVICE DELIVERY OR TARGET FAILURE. This iSCSI response code is also roughly equivalent to an FCP_RSP_LEN_VALID bit set to 1. iSCSI response codes 0x80-0xff are vendor-specific. All other iSCSI response codes are reserved.
  Note

  The SCSI service response is passed to the SAL from the SCSI service delivery subsystem within the initiator. The SCSI service response indicates success or failure for delivery operations. Whereas the iSCSI response code provides status between peer layers in the OSI Reference Model, the SCSI service response provides inter-layer status between provider and subscriber.
  
  
• Status This is 8 bits long. This field contains a status code that provides more detail about the final status of the SCSI command and the state of the logical unit that executed the command. This field is valid only if the Response field is set to 0x00. Even if the Response field is set to 0x00, the target might not have processed the command successfully. If the status code indicates failure to process the command successfully, error information (called SCSI sense data) is included in the Data segment. All iSCSI devices must support SCSI autosense. iSCSI does not define status codes. Instead, iSCSI uses the status codes defined by the SAM. Currently, 10 SCSI status codes are defined in the SAM-3 specification (see Table 8-3). All other values are reserved:
• TotalAHSLength This is 8 bits long.
• DataSegmentLength This is 24 bits long.
• Reserved This is 64 bits (8 bytes) long.
• ITT This is 32 bits long.
• SNACK Tag or Reserved This is 32 bits long. Each SNACK Request PDU is assigned a tag by the initiator. If the initiator sends one or more SNACK Request PDUs for read data after the SCSI Response PDU has been received, the SCSI Response PDU must be discarded. After retransmitting the missing data, the target retransmits the SCSI Response PDU containing the SNACK Tag of the most recently received SNACK Request PDU. The SAM mandates that no more than one status indicator be sent for each SCSI command. However, a single status indicator may be sent more than once. So, a retransmitted SCSI Response PDU always carries the same StatSN as the original PDU. This represents multiple instances of a single status indicator. The initiator must be able to distinguish between multiple instances of the status indicator to process the most recent instance. This field enables the initiator to detect and discard older SCSI Response PDUs. Only the SCSI Response PDU containing the most recent SNACK Tag is considered valid. If the target does not receive any SNACK Request PDUs before sending status, this field is reserved.
• StatSN This is 32 bits long.
• ExpCmdSN This is 32 bits long.
• MaxCmdSN This is 32 bits long. If a SCSI Response PDU is dropped, the target and initiator can temporarily lose synchronization of their MaxCmdSN counters. During this time, the initiator does not know that the target can accept another command. Depending on the current level of I/O activity, this can result in slight performance degradation. Upon receipt of the retransmitted SCSI Response PDU, the MaxCmdSN counters resynchronize, and performance returns to normal.
• ExpDataSN or Reserved This is 32 bits long. This field contains the expected data sequence number. It enables the initiator to verify that all Data-In/Data-Out PDUs were received without error. The target assigns a data sequence number (DataSN) to each Data-In PDU sent during a read command. Likewise, the initiator assigns a DataSN to each Data-Out PDU sent during a write command. For read commands, the ExpDataSN is always calculated as the current DataSN plus one. Therefore, a value of DataSN plus one is always reported in the SCSI Response PDU regardless of whether the read command completes successfully. For write commands, the initiator resets the value of DataSN to 0 upon transmission of the first PDU in each new sequence of PDUs, and the target resets the value of ExpDataSN to 0 after successful reception of each sequence of PDUs. Therefore, a value of 0 is reported in the SCSI Response PDU if the write command completes successfully . If the write command completes unsuccessfully, the value reported in the SCSI Response PDU may vary depending on choices made by the target. In the case of bidirectional commands, the target uses this field to report the number of Data-In and R2T PDUs transmitted. This field is reserved if a command does not complete or if no Data-In PDUs were sent during a read command.
• Bidirectional Read Residual Count or Reserved This is 32 bits long. When the o bit or the u bit is set to 1, this field indicates the residual read byte count for a bidirectional command. When neither the o bit nor the u bit is set to 1, this field is reserved. This field is not used for unidirectional commands. This field is valid only if the Response field is set to 0x00.
• Residual Count or Reserved This is 32 bits long. When either the O bit or the U bit is set to 1, this field indicates the residual read byte count for a read command, the residual write byte count for a write command, or the residual write byte count for a bidirectional command. When neither the O bit nor the U bit is set to 1, this field is reserved. This field is valid only if the Response field is set to 0x00.

Table 8-3 summarizes the SCSI status codes that are currently defined in the SAM-3 specification . All SCSI status codes excluded from Table 8-3 are reserved.

Table 8-3. SCSI Status Codes

Status Code	Status Name	Associated SCSI Service Response
0x00	GOOD	TASK COMPLETE
0x02	CHECK CONDITION	TASK COMPLETE
0x04	CONDITION MET	TASK COMPLETE
0x08	BUSY	TASK COMPLETE
0x10	INTERMEDIATE	LINKED COMMAND COMPLETE
0x14	INTERMEDIATE-CONDITION MET	LINKED COMMAND COMPLETE
0x18	RESERVATION CONFLICT	TASK COMPLETE
0x28	TASK SET FULL	TASK COMPLETE
0x30	ACA ACTIVE	TASK COMPLETE
0x40	TASK ABORTED	TASK COMPLETE

Outbound data is delivered in Data-Out PDUs. Figure 8-9 illustrates the iSCSI BHS of a Data-Out PDU. All fields marked with "." are reserved. Each Data-Out PDU must include a Data segment.

Figure 8-9. iSCSI Data-Out BHS Format

[View full size image]

A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:

• Reserved This is 1 bit.
• Reserved This is the 1 bit redefined as Reserved.
• Opcode This is 6 bits long. It is set to 0x05.
• F This is 1 bit.
• Reserved This is 23 bits long.
• TotalAHSLength This is 8 bits long.
• DataSegmentLength This is 24 bits long.
• LUN or Reserved This is 64 bits (8 bytes) long. Each R2T PDU provides a LUN. All Data-Out PDUs sent in response to an R2T PDU must carry in this field the LUN provided by the R2T PDU. Upon receipt, the target uses this field and the TTT or 0xFFFFFFFF field to associate the Data-Out PDU with a previously transmitted R2T PDU. For Data-Out PDUs containing first burst data, this field is reserved.
• ITT This is 32 bits long.
• Target Transfer Tag (TTT) or 0xFFFFFFFF This is 32 bits long. Each R2T PDU provides a TTT. All Data-Out PDUs sent in response to an R2T PDU must carry in this field the TTT provided by the R2T PDU. Upon receipt, the target uses this field and the LUN or Reserved field to associate the Data-Out PDU with a previously transmitted R2T PDU. For Data-Out PDUs containing first burst data, this field contains the value 0xFFFFFFFF.
• Reserved This is 32 bits long.
• ExpStatSN This is 32 bits long.
• Reserved This is 32 bits long.
• Data Sequence Number (DataSN) This is 32 bits long. This field uniquely identifies each Data-Out PDU within each sequence of PDUs. The DataSN is similar in function to the FC SEQ_ID. Each SCSI write command is satisfied with one or more sequences of PDUs. Each PDU sequence is identified by the ITT (for unsolicited data) or the TTT (for solicited data). This field is incremented by one for each Data-Out PDU transmitted within a sequence. A retransmitted Data-Out PDU carries the same DataSN as the original PDU. The counter is reset for each new sequence within the context a single command.
• Buffer Offset This is 32 bits long. This field indicates the position of the first byte of data delivered by this PDU relative to the first byte of all the data transferred by the associated SCSI command. This field enables the target to reassemble the data properly.
• Reserved This is 32 bits long.

Inbound data is delivered in Data-In PDUs. Figure 8-10 illustrates the iSCSI BHS of a Data-In PDU. All fields marked with "." are reserved. Each Data-In PDU must include a Data segment.

Figure 8-10. iSCSI Data-In BHS Format

[View full size image]

A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:

• Reserved This is 1 bit.
• Reserved This is the 1 bit redefined as Reserved.
• Opcode This is 6 bits long. It is set to 0x25.
• F bit This may be set to 1 before sending the final Data-In PDU. Doing so indicates a change of direction during a bidirectional command. When used to change the direction of transfer, this bit is similar in function to the FC Sequence Initiative bit in the F_CTL field in the FC Header.
• A This is 1 bit. The A stands for Acknowledge. The target sets this bit to 1 to request positive, cumulative acknowledgment of all Data-In PDUs transmitted before the current Data-In PDU. This bit may be used only if the session supports an ErrorRecoveryLevel greater than 0 (see the iSCSI Login Parameters section of this chapter).
• Reserved This is 3 bits long.
• O and U bits These are used in the same manner as previously described. These bits are present to support phase-collapse for read commands. For bidirectional commands, the target must send status in a separate SCSI Response PDU. iSCSI (like FCP) does not support status phase-collapse for write commands. These bits are valid only when the S bit is set to 1.
• S This is 1 bit. The S stands for status. When this bit is set to 1, status is included in the PDU.
• Reserved This is 8 bits long.
• Status or Reserved This is 8 bits long. When the S field is set to 1, this field contains the SCSI status code for the command. Phase-collapse is supported only when the iSCSI response code is 0x00. Thus, a Response field is not required because the response code is implied. Furthermore, phase-collapse is supported only when the SCSI status is 0x00, 0x04, 0x10, or 0x14 (GOOD, CONDITION MET, INTERMEDIATE, or INTERMEDIATE-CONDITION MET, respectively). When the S field is set to zero, this field is reserved.
• TotalAHSLength This is 8 bits long.
• DataSegmentLength This is 24 bits long.
• LUN or Reserved This is 64 bits (8 bytes) long and contains the LUN if the A field is set to 1. The initiator copies the value of this field into a similar field in the acknowledgment PDU. If the A field is set to 0, this field is reserved.
• ITT This is 32 bits long.
• TTT or 0xFFFFFFFF This is 32 bits long. It contains a TTT if the A field is set to 1. The initiator copies the value of this field into a similar field in the acknowledgment PDU. If the A field is set to 0, this field is set to 0xFFFFFFFF.
• StatSN or Reserved This is 32 bits long. It contains the StatSN if the S field is set to 1. Otherwise, this field is reserved.
• ExpCmdSN This is 32 bits long.
• MaxCmdSN This is 32 bits long.
• DataSN This is 32 bits long. It uniquely identifies each Data-In PDU within a sequence of PDUs. The DataSN is similar in function to the FC SEQ_ID. Each SCSI read command is satisfied with a single sequence of PDUs. Each PDU sequence is identified by the CmdSN. This field is incremented by 1 for each Data-In PDU transmitted within a SCSI task. A retransmitted Data-In PDU carries the same DataSN as the original PDU. The DataSN counter does not reset within a single read command or after each linked read command within a single SCSI task. Likewise, for bidirectional commands in which the target periodically sets the F field to 1 to allow the transfer of write data, the DataSN counter does not reset after each sequence. This field is also incremented by one for each R2T PDU transmitted during bidirectional command processing . In other words, the target maintains a single counter for both DataSN and R2T Sequence Number (R2TSN) during bidirectional command processing.
• Buffer Offset This is 32 bits long.
• Residual Count This is 32 bits long. It is used in the same manner as previously described. This field is present to support phase-collapse for read commands. This field is valid only when the S field is set to 1.