iSCSI Operational DetailsThis section provides an in-depth exploration of the operational details of iSCSI. This section complements and builds upon the iSCSI overview provided in Chapter 4, "Overview of Modern SCSI Networking Protocols." You are also encouraged to consult IETF RFC 3347 for an overview of the requirements that shaped the development of iSCSI. iSCSI Addressing SchemeiSCSI 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. 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
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 (see Chapter 5, "OSI Physical and Data-Link Layers"). 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
The NAA type is based on the ANSI T11 NAA scheme. As explained in Chapter 5, 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
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. 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
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). Recall from Chapter 5 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
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:
Table 8-1 summarizes the possible values of T and the associated field descriptions.
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. iSCSI Name Assignment and ResolutioniSCSI 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 (see Chapter 3, "Overview of Network Operating Principles"), three methods of name resolution exist: manual, semi-manual, and automated. 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. 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). 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. iSCSI Address Assignment and ResolutionAs 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. iSCSI Session Types, Phases, and StagesAs discussed in Chapter 3, 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 iSCSI Data Transfer OptimizationsiSCSI 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. 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 forimmediate 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. iSCSI PDU FormatsiSCSI 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
A brief description of each field follows:
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 FormatA brief description of each field follows:
Table 8-2 summarizes the iSCSI opcodes that are currently defined in RFC 3720. All opcodes excluded from Table 8-2 are reserved.
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 FormatA brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
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
A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
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 FormatA brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
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 A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
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.
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 A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
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 A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
The target signals its readiness to receive write data via the R2T PDU. The target also uses the R2T PDU to request retransmission of missing Data-Out PDUs. In both cases, the PDU format is the same, but an R2T PDU sent to request retransmission is called a Recovery R2T PDU. Figure 8-11 illustrates the iSCSI BHS of a R2T PDU. All fields marked with "." are reserved.
Figure 8-11. iSCSI R2T BHS Format A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
iSCSI supports PDU retransmission and PDU delivery acknowledgment on demand via the SNACK Request PDU. Each SNACK Request PDU specifies a contiguous set of missing single-type PDUs. Each set is called a run. Figure 8-12 illustrates the iSCSI BHS of a SNACK Request PDU. All fields marked with "." are reserved. Figure 8-12. iSCSI SNACK Request BHS FormatA brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
Table 8-4 summarizes the SNACK Request PDU types that are currently defined in RFC 3720. All PDU types excluded from Table 8-4 are reserved.
iSCSI initiators manage SCSI and iSCSI tasks via the TMF Request PDU. Figure 8-13 illustrates the iSCSI BHS of a TMF Request PDU. All fields marked with "." are reserved.
Figure 8-13. iSCSI TMF Request BHS Format A brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
Table 8-5 summarizes the TMF Request codes that are currently supported by iSCSI. All TMF Request codes excluded from Table 8-5 are reserved.
Each TMF Request PDU precipitates one TMF Response PDU. Figure 8-14 illustrates the iSCSI BHS of a TMF Response PDU. All fields marked with "." are reserved. Figure 8-14. iSCSI TMF Response BHS FormatA brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
Table 8-6 summarizes the TMF Response codes that are currently supported by iSCSI. All TMF Response codes excluded from Table 8-6 are reserved. The Reject PDU signals an error condition and rejects the PDU that caused the error. The Data segment (not shown in Figure 8-15) must contain the header of the PDU that caused the error. If a Reject PDU causes a task to terminate, a SCSI Response PDU with status CHECK CONDITION must be sent. Figure 8-15 illustrates the iSCSI BHS of a Reject PDU. All fields marked with "." are reserved.
Figure 8-15. iSCSI Reject BHS FormatA brief description of each field follows. The description of each field is abbreviated unless a field is used in a PDU-specific manner:
Table 8-7 summarizes the Reject Reason codes that are currently supported by iSCSI. All Reject Reason codes excluded from Table 8-7 are reserved. The preceding discussion of iSCSI PDU formats is simplified for the sake of clarity. Comprehensive exploration of all the iSCSI PDUs and their variations is outside the scope of this book. For more information, readers are encouraged to consult IETF RFC 3720 and the ANSI T10 SAM-2, SAM-3, SPC-2, and SPC-3 specifications. iSCSI Login ParametersDuring the Login Phase, security and operating parameters are exchanged as text key-value pairs. As previously stated, text keys are encapsulated in the Data segment of the Login Request and Login Response PDUs. Some operating parameters may be re-negotiated after the Login Phase completes (during the Full Feature Phase) via the Text Request and Text Response PDUs. However, most operating parameters remain unchanged for the duration of a session. Security parameters may not be re-negotiated during an active session. Some text keys have a session-wide scope, and others have a connection-specific scope. Some text keys may be exchanged only during negotiation of the leading connection for a new session. Some text keys require a response (negotiation), and others do not (declaration). Currently, RFC 3720 defines 22 operational text keys. RFC 3720 also defines a protocol extension mechanism that enables the use of public and private text keys that are not defined in RFC 3720. This section describes the standard operational text keys and the extension mechanism. The format of all text key-value pairs is:
The SessionType key declares the type of iSCSI session. Only initiators send this key. This key must be sent only during the Login Phase on the leading connection. The valid values are Normal and Discovery. The default value is Normal. The scope is session-wide. The HeaderDigest and DataDigest keys negotiate the use of the Header-Digest segment and the Data-Digest segment, respectively. Initiators and targets send these keys. These keys may be sent only during the Login Phase. Values that must be supported include CRC32C and None. Other public and private algorithms may be supported. The default value is None for both keys. The chosen digest must be used in every PDU sent during the Full Feature Phase. The scope is connection-specific. As discussed in Chapter 3, the SendTargets key is used by initiators to discover targets during a Discovery session. This key may also be sent by initiators during a Normal session to discover changed or additional paths to a known target. Sending this key during a Normal session is fruitful only if the target configuration changes after the Login Phase. This is because, during a Discovery session, a target network entity must return all target names, sockets, and TPGTs for all targets that the requesting initiator is permitted to access. Additionally, path changes occurring during the Login Phase of a Normal session are handled via redirection. This key may be sent only during the Full Feature Phase. The scope is session-wide. The TargetName key declares the iSCSI device name of one or more target devices within the responding network entity. This key may be sent by targets only in response to a SendTargets command. This key may be sent by initiators only during the Login Phase of a Normal session, and the key must be included in the leading Login Request PDU for each connection. The scope is session-wide. The TargetAddress key declares the network addresses, TCP ports, and TPGTs of the target device to the initiator device. An address may be given in the form of DNS host name, IPv4 address, or IPv6 address. The TCP port may be omitted if the default port of 3260 is used. Only targets send this key. This key is usually sent in response to a SendTargets command, but it may be sent in a Login Response PDU to redirect an initiator. Therefore, this key may be sent during any phase. The scope is session-wide. The InitiatorName key declares the iSCSI device name of the initiator device within the initiating network entity. This key identifies the initiator device to the target device so that access controls can be implemented. Only initiators send this key. This key may be sent only during the Login Phase, and the key must be included in the leading Login Request PDU for each connection. The scope is session-wide. The InitiatorAlias key declares the optional human-friendly name of the initiator device to the target for display in relevant user interfaces. Only initiators send this key. This key is usually sent in a Login Request PDU for a Normal session, but it may be sent during the Full Feature Phase as well. The scope is session-wide. The TargetAlias key declares the optional human-friendly name of the target device to the initiator for display in relevant user interfaces. Only targets send this key. This key usually is sent in a Login Response PDU for a Normal session, but it may be sent during the Full Feature Phase as well. The scope is session-wide. The TargetPortalGroupTag key declares the TPGT of the target port to the initiator port. Only targets send this key. This key must be sent in the first Login Response PDU of a Normal session unless the first Login Response PDU redirects the initiator to another TargetAddress. The range of valid values is 0 to 65,535. The scope is session-wide. The ImmediateData and InitialR2T keys negotiate support for immediate data and unsolicited data, respectively. Immediate data may not be sent unless both devices support immediate data. Unsolicited data may not be sent unless both devices support unsolicited data. Initiators and targets send these keys. These keys may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. The default settings support immediate data but not unsolicited data. The scope is session-wide for both keys. The MaxOutstandingR2T key negotiates the maximum number of R2T PDUs that may be outstanding simultaneously for a single task. This key does not include the implicit R2T PDU associated with unsolicited data. Each R2T PDU is considered outstanding until the last Data-Out PDU is transferred (initiator's perspective) or received (target's perspective). A sequence timeout can also terminate the lifespan of an R2T PDU. Initiators and targets send this key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. The range of valid values is 1 to 65,535. The default value is one. The scope is session-wide. The MaxRecvDataSegmentLength key declares the maximum amount of data that a receiver (initiator or target) can receive in a single iSCSI PDU. Initiators and targets send this key. This key may be sent during any phase of any session type and is usually sent during the Login Phase on the leading connection. This key is expressed in bytes. The range of valid values is 512 to 16,777,215. The default value is 8,192. The scope is connection-specific. The MaxBurstLength key negotiates the maximum amount of data that a receiver (initiator or target) can receive in a single iSCSI sequence. This value may exceed the value of MaxRecvDataSegmentLength, which means that more than one PDU may be sent in response to an R2T Request PDU. This contrasts the FC model. For write commands, this key applies only to solicited data. Initiators and targets send this key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. This key is expressed in bytes. The range of valid values is 512 to 16,777,215. The default value is 262,144. The scope is session-wide. The FirstBurstLength key negotiates the maximum amount of data that a target can receive in a single iSCSI sequence of unsolicited data (including immediate data). Thus, the value of this key minus the amount of immediate data received with the SCSI command PDU yields the amount of unsolicited data that the target can receive in the same sequence. If neither immediate data nor unsolicited data is supported within the session, this key is invalid. The value of this key cannot exceed the target's MaxBurstLength. Initiators and targets send this key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. This key is expressed in bytes. The range of valid values is 512 to 16,777,215. The default value is 65,536. The scope is session-wide. The MaxConnections key negotiates the maximum number of TCP connections supported by a session. Initiators and targets send this key. Discovery sessions are restricted to one TCP connection, so this key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. The range of valid values is 1 to 65,535. The default is value is 1. The scope is session-wide. The DefaultTime2Wait key negotiates the amount of time that must pass before attempting to logout a failed connection. Task reassignment may not occur until after the failed connection is logged out. Initiators and targets send this key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. This key is expressed in seconds. The range of valid values is 0 to 3600. The default value is 2. A value of 0 indicates that logout may be attempted immediately upon detection of a failed connection. The scope is session-wide. The DefaultTime2Retain key negotiates the amount of time that task state information must be retained for active tasks after DefaultTime2Wait expires. When a connection fails, this key determines how much time is available to complete task reassignment. If the failed connection is the last (or only) connection in a session, this key also represents the session timeout value. Initiators and targets send this key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. This key is expressed in seconds. The range of valid values is 0 to 3600. The default value is 20. A value of 0 indicates that task state information is discarded immediately upon detection of a failed connection. The scope is session-wide. The DataPDUInOrder key negotiates in-order transmission of data PDUs within a sequence. Because TCP guarantees in-order delivery, the only way for PDUs of a given sequence to arrive out of order is to be transmitted out of order. Initiators and targets send this key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. The default value requires in-order transmission. The scope is session-wide. The DataSequenceInOrder key negotiates in-order transmission of data PDU sequences within a command. For sessions that support in-order transmission of sequences and retransmission of missing data PDUs (ErrorRecoveryLevel greater than zero), the MaxOustandingR2T key must be set to 1. This is because requests for retransmission may be sent only for the lowest outstanding R2TSN, and all PDUs already received for a higher outstanding R2TSN must be discarded until retransmission succeeds. This is inefficient. It undermines the goal of multiple outstanding R2T PDUs. Sessions that do not support retransmission must terminate the appropriate task upon detection of a missing data PDU, and all data PDUs must be retransmitted via a new task. Thus, no additional inefficiency is introduced by supporting multiple outstanding R2T PDUs when the ErrorRecoveryLevel key is set to 0. Initiators and targets send the DataSequenceInOrder key. This key may be sent only during Normal sessions and must be sent during the Login Phase on the leading connection. The default value requires in-order transmission. The scope is session-wide. The ErrorRecoveryLevel key negotiates the combination of recovery mechanisms supported by the session. Initiators and targets send this key. This key may be sent only during the Login Phase on the leading connection. The range of valid values is 0 to 2. The default value is 0. The scope is session-wide. The OFMarker and IFMarker keys negotiate support for PDU boundary detection via the fixed interval markers (FIM) scheme. Initiators and targets send these keys. These keys may be sent during any session type and must be sent during the Login Phase. The default setting is disabled for both keys. The scope is connection-specific. The OFMarkInt and IFMarkInt keys negotiate the interval for the FIM scheme. These keys are valid only if the FIM scheme is used. Initiators and targets send these keys. These keys may be sent during any session type and must be sent during the Login Phase. These keys are expressed in 4-byte words. The range of valid values is 1 to 65,535. The default value is 2048 for both keys. The scope is connection-specific. A mechanism is defined to enable implementers to extend the iSCSI protocol via additional key-value pairs. These are known as private and public extension keys. Support for private and public extension keys is optional. Private extension keys are proprietary. All private extension keys begin with "X-" to convey their proprietary status. Public extension keys must be registered with the IANA and must also be described in an informational RFC published by the IETF. All public extension keys begin with "X#" to convey their registered status. Private extension keys may be used only in Normal sessions but are not limited by phase. Public extension keys may be used in either type of session and are not limited by phase. Initiators and targets may send private and public extension keys. The scope of each extension key is determined by the rules of that key. The format of private extension keys is flexible but generally takes the form:
The format of public extension keys is mandated as:
For more information about iSCSI text key-value pairs, readers are encouraged to consult IETF RFC 3720. iSCSI Delivery MechanismsThe checksum used by TCP does not detect all errors. Therefore, iSCSI must use its own CRC-based digests (as does FC) to ensure the utmost data integrity. This has two implications:
Additionally, problems can occur in a routed IP network that cause a TCP connection or an iSCSI session to fail. Currently, this does not occur frequently in iSCSI environments because most iSCSI deployments are single-subnet environments. However, iSCSI is designed in a such a way that it supports operation in routed IP networks. Specifically, iSCSI supports connection and session recovery to prevent IP network problems from affecting the SAL. This enables iSCSI users to realize the full potential of TCP/IP. RFC 3720 defines several delivery mechanisms to meet all these requirements. Error Recovery ClassesRFC 3720 permits each iSCSI implementation to select its own recovery capabilities. Recovery capabilities are grouped into classes to simplify implementation and promote interoperability. Four classes of recoverability are defined:
RFC 3720 mandates the minimum recovery class that may be used for each type of error. RFC 3720 does not provide a comprehensive list of errors, but does provide representative examples. An iSCSI implementation may use a higher recovery class than the minimum required for a given error. Both initiator and target are allowed to escalate the recovery class. The number of tasks that are potentially affected increases with each higher class. So, use of the lowest possible class is encouraged. The two lowest classes may be used in only the Full Feature Phase of a session. Table 8-8 lists some example scenarios for each recovery class.
Error Recovery HierarchyRFC 3720 defines three error recovery levels that map to the four error recovery classes. The three recovery levels are referred to as the Error Recovery Hierarchy. During the Login Phase, the recovery level is negotiated via the ErrorRecoveryLevel key. Each recovery level is a superset of the capabilities of the lower level. Thus, support for a higher level indicates a more sophisticated iSCSI implementation. Table 8-9summarizes the mapping of levels to classes.
At first glance, the mapping of levels to classes may seem counter-intuitive. The mapping is easier to understand after examining the implementation complexity of each recovery class. The goal of iSCSI recovery is to avoid affecting the SAL. However, an iSCSI implementation may choose not to recover from errors. In this case, recovery is left to the SCSI application client. Such is the case with ErrorRecoveryLevel 0, which simply terminates the failed session and creates a new session. The SCSI application client is responsible for reissuing all affected tasks. Therefore, ErrorRecoveryLevel 0 is the simplest to implement. Recovery within a command and recovery within a connection both require iSCSI to retransmit one or more PDUs. Therefore, ErrorRecoveryLevel 1 is more complex to implement. Recovery of a connection requires iSCSI to maintain state for one or more tasks so that task reassignment may occur. Recovery of a connection also requires iSCSI to retransmit one or more PDUs on the new connection. Therefore, ErrorRecoveryLevel 2 is the most complex to implement. Only ErrorRecoveryLevel 0 must be supported. Support for ErrorRecoveryLevel 1 and higher is encouraged but not required. PDU Boundary DetectionTo determine the total length of a PDU without relying solely on the iSCSI BHS, RFC 3720 permits the use of message synchronization schemes. Even though RFC 3720 encourages the use of such schemes, no such scheme is mandated. That said, a practical requirement for such schemes arises from the simultaneous implementation of header digests and ErrorRecoveryLevel 1 or higher. As a reference for implementers, RFC 3720 provides the details of a scheme called fixed interval markers (FIM). The FIM scheme works by inserting an 8-byte marker into the TCP stream at fixed intervals. Both the initiator and target may insert the markers. Each marker contains two copies of a 4-byte pointer that indicates the starting byte number of the next iSCSI PDU. Support for the FIM scheme is negotiated during the Login Phase. PDU RetransmissioniSCSI guarantees in-order data delivery to the SAL. When PDUs arrive out of order due to retransmission, the iSCSI protocol does not reorder PDUs per se. Upon receipt of all TCP packets composing an iSCSI PDU, iSCSI places the ULP data in an application buffer. The position of the data within the application buffer is determined by the Buffer Offset field in the BHS of the Data-In/Data-Out PDU. When an iSCSI digest error, or a dropped or delayed TCP packet causes a processing delay for a given iSCSI PDU, the Buffer Offset field in the BHS of other iSCSI data PDUs that are received error-free enables continued processing without delay regardless of PDU transmission order. Thus, iSCSI PDUs do not need to be reordered before processing. Of course, the use of a message synchronization scheme is required under certain circumstances for PDU processing to continue in the presence of one or more dropped or delayed PDUs. Otherwise, the BHS of subsequent PDUs cannot be read. Assuming this requirement is met, PDUs can be processed in any order. Retransmission occurs as the result of a digest error, protocol error, or timeout. Despite differences in detection techniques, PDU retransmission is handled in a similar manner for data digest errors, protocol errors and timeouts. However, header digest errors require special handling. When a header digest error occurs, and the connection does not support a PDU boundary detection scheme, the connection must be terminated. If the session supports ErrorRecoveryLevel 2, the connection is recovered, tasks are reassigned, and PDU retransmission occurs on the new connection. If the session does not support ErrorRecoveryLevel 2, the connection is not recovered. In this case, the SCSI application client must re-issue the terminated tasks on another connection within the same session. If no other connections exist with the same session, the session is terminated, and the SCSI application client must re-issue the terminated tasks in a new session. When a header digest error occurs, and the connection supports a PDU boundary detection scheme, the PDU is discarded. If the session supports ErrorRecoveryLevel 1 or higher, retransmission of the dropped PDU is handled as described in the following paragraphs. Note that detection of a dropped PDU because of header digest error requires successful receipt of a subsequent PDU associated with the same task. If the session supports only ErrorRecoveryLevel 0, the session is terminated, and the SCSI application client must re-issue the terminated tasks in a new session. The remainder of this section focuses primarily on PDU retransmission in the presence of data digest errors. Targets explicitly notify initiators when a PDU is dropped because of data digest failure. The Reject PDU facilitates such notification. Receipt of a Reject PDU for a SCSI Command PDU containing immediate data triggers retransmission if ErrorRecoveryLevel is 1 or higher. When an initiator retransmits a SCSI Command PDU, certain fields (such as the ITT, CmdSN, and operational attributes) in the BHS must be identical to the original PDU's BHS. This is known as a retry. A retry must be sent on the same connection as the original PDU unless the connection is no longer active. Receipt of a Reject PDU for a SCSI Command PDU that does not contain immediate data usually indicates a non-digest error that prevents retrying the command. Receipt of a Reject PDU for a Data-Out PDU does not trigger retransmission. Initiators retransmit Data-Out PDUs only in response to Recovery R2T PDUs. Thus, targets are responsible for requesting retransmission of missing Data-Out PDUs if ErrorRecoveryLevel is 1 or higher. Efficient recovery of dropped data during write operations is accomplished via the Buffer Offset and Desired Data Transfer Length fields in the Recovery R2T PDU. In the absence of a Recovery R2T PDU (in other words, when no Data-Out PDUs are dropped), all Data-Out PDUs are implicitly acknowledged by a SCSI status of GOOD in the SCSI Response PDU. When a connection fails and tasks are reassigned, the initiator retransmits a SCSI Command PDU or Data-Out PDUs as appropriate for each task in response to Recovery R2T PDUs sent by the target on the new connection. When a session fails, an iSCSI initiator does not retransmit any PDUs. At any point in time, an initiator may send a No Operation Out (NOP-Out) PDU to probe the sequence numbers of a target and to convey the initiator's sequence numbers to the same target. Initiators also use the NOP-Out PDU to respond to No Operation IN (NOP-In) PDUs received from a target. A NOP-Out PDU may also be used for diagnostic purposes or to adjust timeout values. A NOP-Out PDU does not directly trigger retransmission. Initiators do not explicitly notify targets when a Data-In PDU or SCSI Response PDU is dropped due to data digest failure. Because R2T PDUs do not contain data, detection of a missing R2T PDU via an out-of-order R2TSN means a header digest error occurred on the original R2T PDU. When a Data-In PDU or SCSI Response PDU containing data is dropped, the initiator requests retransmission via a Data/R2T SNACK Request PDU if ErrorRecoveryLevel is 1 or higher. Efficient recovery of dropped data during read operations is accomplished via the BegRun and RunLength fields in the SNACK Request PDU. The target infers that all Data-In PDUs associated with a given command were received based on the ExpStatSN field in the BHS of a subsequent SCSI Command PDU or Data-Out PDU. Until such acknowledgment is inferred, the target must be able to retransmit all data associated with a command. This requirement can consume a lot of the target's resources during long read operations. To free resources during long read operations, targets may periodically request explicit acknowledgment of Data-In PDU receipt via a DataACK SNACK Request PDU. When a connection fails and tasks are reassigned, the target retransmits Data-In PDUs or a SCSI Response PDU as appropriate for each task. Initiators are not required to explicitly request retransmission following connection recovery. All unacknowledged Data-In PDUs and SCSI Response PDUs must be automatically retransmitted after connection recovery. The target uses the ExpDataSN of the most recent DataACK SNACK Request PDU to determine which Data-IN PDUs must be retransmitted for each task. Optionally, the target may use the ExpDataSN field in the TMF Request PDU received from the initiator after task reassignment to determine which Data-In PDUs must be retransmitted for each task. If the target cannot reliably maintain state for a reassigned task, all Data-In PDUs associated with that task must be retransmitted. If the SCSI Response PDU for a given task was transmitted before task reassignment, the PDU must be retransmitted after task reassignment. Otherwise, the SCSI Response PDU is transmitted at the conclusion of the command or task as usual. When a session fails, an iSCSI target does not retransmit any PDUs. At any point in time, a target may send a NOP-In PDU to probe the sequence numbers of an initiator and to convey the target's sequence numbers to the same initiator. Targets also use the NOP-In PDU to respond to NOP-Out PDUs received from an initiator. A NOP-In PDU may also be used for diagnostic purposes or to adjust timeout values. A NOP-In PDU does not directly trigger retransmission. iSCSI In-Order Command DeliveryAccording to the SAM, status received for a command finalizes the command under all circumstances. So, initiators requiring in-order delivery of commands can simply restrict the number of outstanding commands to one and wait for status for each outstanding command before issuing the next command. Alternately, the SCSI Transport Protocol can guarantee in-order command delivery. This enables the initiator to maintain multiple simultaneous outstanding commands. iSCSI guarantees in-order delivery of non-immediate commands to the SAL within a target. Each non-immediate command is assigned a unique CmdSN. The CmdSN counter must be incremented sequentially for each new non-immediate command without skipping numbers. In a single-connection session, the in-order guarantee is inherent due to the properties of TCP. In a multi-connection session, commands are issued sequentially across all connections. In this scenario, TCP cannot guarantee in-order delivery of non-immediate commands because TCP operates independently on each connection. Additionally, the configuration of a routed IP network can result in one connection using a "shorter" route to the destination node than other connections. Thus, iSCSI must augment TCP by ensuring that non-immediate commands are processed in order (according to the CmdSN) across multiple connections. So, RFC 3720 requires each target to process non-immediate commands in the same order as transmitted by the initiator. Note that a CmdSN is assigned to each TMF Request PDU. The rules of in-order delivery also apply to non-immediate TMF requests. Immediate commands are handled differently than non-immediate commands. An immediate command is not assigned a unique CmdSN and is not subject to in-order delivery guarantees. The initiator increments its CmdSN counter after transmitting a new non-immediate command. Thus, the value of the initiator's CmdSN counter (the current CmdSN) represents the CmdSN of the next non-immediate command to be issued. The current CmdSN is also assigned to each immediate command issued, but the CmdSN counter is not incremented following issuance of immediate commands. Moreover, the target may deliver immediate commands to the SAL immediately upon receipt regardless of the CmdSN in the BHS. The next non-immediate command is assigned the same CmdSN. For that PDU, the CmdSN in the BHS is used by the target to enforce in-order delivery. Thus, immediate commands are not acknowledged via the ExpCmdSN field in the BHS. Immediate TMF requests are processed like non-immediate TMF requests. Therefore, marking a TMF request for immediate delivery does not expedite processing. Note The order of command delivery does not necessarily translate to the order of command execution. The order of command execution can be changed via TMF request as specified in the SCSI standards. iSCSI Connection and Session RecoveryWhen ErrorRecoveryLevel equals 2, iSCSI supports stateful recovery at the connection level. Targets may choose whether to maintain state during connection recovery. When state is maintained, active commands are reassigned, and data transfer resumes on the new connection from the point at which data receipt is acknowledged. When state is not maintained, active commands are reassigned, and all associated data must be transferred on the new connection. Connections may be reinstated or recovered. Reinstatement means that the same CID is reused. Recovery means that a new CID is assigned. RFC 3720 does not clearly define these terms, but the definitions provided herein appear to be accurate. When MaxConnections equals one, and ErrorRecoveryLevel equals two, the session must temporarily override the MaxConnections parameter during connection recovery. Two connections must be simultaneously supported during recovery. Additionally, the failed connection must be cleaned up before recovery to avoid receipt of stale PDUs following recovery. In a multi-connection session, each command is allegiant to a single connection. In other words, all PDUs associated with a given command must traverse a single connection. This is known as connection allegiance. Connection allegiance is command-oriented, not task-oriented. This can be confusing because connection recovery involves task reassignment. When a connection fails, an active command is identified by its ITT (not CmdSN) for reassignment purposes. This is because SCSI defines management functions at the task level, not at the command level. However, multiple commands can be issued with a single ITT (linked commands), and each linked command can be issued on a different connection within a single session. No more than one linked command can be outstanding at any point in time for a given task, so the ITT uniquely identifies each linked command during connection recovery. The PDUs associated with each linked command must traverse the connection on which the command was issued. This means a task may be spread across multiple connections over time, but each command is allegiant to a single connection at any point in time. When a session is recovered, iSCSI establishes a new session on behalf of the SCSI application client. iSCSI also terminates all active tasks within the target and generates a SCSI response for the SCSI application client. iSCSI does not maintain any state for outstanding tasks. All tasks must be reissued by the SCSI application client. The preceding discussion of iSCSI delivery mechanisms is simplified for the sake of clarity. For more information about iSCSI delivery mechanisms, readers are encouraged to consult IETF RFCs 3720 and 3783. |
iSCSI Operational Details
最新推荐文章于 2024-03-22 17:11:07 发布