iscsi A Revolutionary IP based SAN

Transcription

1 Volume 2, Issue 3, June 2013 iscsi A Revolutionary IP based SAN Sandeep Gupta Abstract - The storage area network, or SAN, allows many servers to share data storage, while providing high-performance access to their data. The SAN can make backups easier to perform, reduce data management overhead, and boost return on investment in data storage hardware. It can also improve data availability. Historically in storage environments, physical interfaces to storage consisted of parallel SCSI channels supporting a small number of directly connected/dedicated SCSI devices. Today s storage technology relies mainly on computer networks as they centralize storage needs, reduce the cost of storage area, increase the possibilities of disaster recovery and improve the data backup and restore process efficiency. The existing protocols depend on the type of network and the type of application the end user is running. The transfer of data from the end user station to the network central storage space is either as files or as low-level blocks of data. The use of SCSI protocols for implementation of different storage protocols is common. The SCSI protocol is based on block data transfer. The SAN based on the Fibre Communication has some disadvantages, which are the price and difficulties of access to remote devices. Moreover the limitation became obvious when the storage need was on a network that was geographically spread. Small and midsize businesses that thought the cost of implementation for SAN was huge got a breather with IP based SAN technology. In the IP based SAN technology the TCP/IP network substituted for the fibre-channel hence, removing the dependence of SAN on high cost fibre channel networks. The recent support of Internet Small Computer System Interface (iscsi) has had a revolutionary effect in this field. The development and standardization of the iscsi transport protocol came as the first challenge to the dominance of fibre Channel. The fact that iscsi can be implemented on the existing TCP/IP network without the need for a special network fabric gives iscsi an advantage over other storage protocols that are based on special high cost fibre channel networks. Hence iscsi has given SAN a boost by making it a cheaper technology to implement, still providing all the finer features that are expectations from a SAN implementation. This paper is targeted to an audience who are interested in working of iscsi, especially the implementation part of this emerging new technology. It outlines the details of iscsi technology to provide for the information regarding the iscsi is an end-to-end protocol that connects the end user stations to the network storage pool over the existing TCP/IP network infrastructure. It provides for support to HBAs as well, hence they can be implemented completely on HBAs. An iscsi-based network consists typically of: iscsi enabled server and the storage devices. A TCP/IP network infrastructure with Ethernet interface cards or HBAs. Multi-protocol iscsi enabled switches if the SAN is FC based. The end user station (iscsi initiator) initiates the data storage towards an iscsi target device. The iscsi target device is the iscsi server with the storage devices. The storage traffic from an initiator does not end at sever, its actually aimed at the LUNs of the storage devices. II. THE ISCSI PROTOCOL MODEL The iscsi protocol is basically a storage based client server protocol, which transfers low-level blocks of storage data between the storage server and the client. The specific storage area or the LUN in the server is called the iscsi target and the client is called the iscsi initiator. The iscsi protocol provides for encapsulation of SCSI commands over the TCP/IP stack. The encapsulation of SCSI packets and the protocol stack order is as shown below. iscsi Initiator Node Application iscsi Target Node Logical Unit implementation of iscsi technology and its standards. It goes further to explain the protocol data unit (PDU) structure with the example of the login request and response PDUs. The detail of all the PDUs is out of the scope of this document. Index Terms SAN, iscsi, PDU, TCP/IP, HBA, LUN, CBD SCSI Driver iscsi Protocol SCSI Driver iscsi Protocol I. AN INTRODUCTION TO iscsi TCP/IP Layer TCP/IP Layer iscsi is a network storage protocol based on transfer of block oriented storage data. The iscsi protocol is a standard that is a base for transmission of the SCSI storage protocol over the well-established Transmission Control Protocol/Internet Protocol (TCP/IP) networking protocol stack. The iscsi protocol defines the rules and processes for transmitting and receiving block storage data as SCSI packets over TCP/IP networks. Ethernet Ethernet Physical communication medium Figure 1: iscsi Protocol Stack 4

2 Volume 3, Issue 3, June 2013 The applications at the iscsi initiator end makes the data transfer requests; the SCSI driver converts these requests into Command Description blocks or CDBs. These CDBs are then passed on to the iscsi layer, which encapsulates the CDBs into Protocol Data Units or PDUs. The PDUs at the iscsi layer carry information regarding the specific target such the logical unit number of the destination device. The iscsi layer PDU then goes down the TCP/IP stack where each layer adds additional information in the respective headers. This packet is then transported to the target end over the network infrastructure. The figure below depicts the SCSI command encapsulation. IP Header TCP Header iscsi Header SCSI command packet Figure 2. SCSI commands encapsulation During the write request from the applications at the initiator end the SCSI commands are encapsulated at the initiator end, and for the read requests the commands are encapsulated at the target end. PDUs are also defined for controlling the flow of data and target responses. Communication between the initiator and target occurs over one or more TCP connections. The TCP connections carry control messages, SCSI commands, parameters, and data within iscsi Protocol Data Units (iscsi PDUs). The group of TCP connections that link an initiator with a target form a session. A session is defined by a session ID that is composed of an initiator part and a target part. TCP connections can be added and removed from a session. Each connection within a session is identified by a connection ID (CID). Across all connections within a session, an initiator sees one "Target Image". All target-identifying elements, such as LUN, are same. A target also sees one "initiator image" across all connections within a session. Initiator identifying elements, such as the Initiator Task Tag, are global across the session regardless of the connection on which they are sent or received. iscsi uses Command and Status numbering schemes and a Data sequencing scheme. Command numbering is session-wide and is used for ordered command delivery over multiple connections. It can also be used as a mechanism for command flow control over a session. iscsi performs ordered command delivery within a session. All commands (initiator-to-target PDUs) in transit from the initiator to the target are numbered. iscsi considers a task to be instantiated on the target in response to every request issued by the initiator and each task is identified by the Initiator task tag as long as the task is valid. The command sequence number is carried in the iscsi PDU in the CmdSn field. The numbering is session-wide and all the outgoing iscsi PDUs carry this sequence number. Command sequencing starts with the first login request in the first session, then on the command sequence number is incremented. The command sequence number is not incremented if the command is marked for immediate delivery. The iscsi commands in a task are executed as per their sequence numbers. The command sequencing is implemented using three fields in the PDU: CmdSn: The current sequence number. ExpCmdSn: The next command expected by the target. The target will acknowledge all the commands with CmdSn lower than ExpCmdSn value. MaxCmdSn: Maximum number of commands that can be shipped. Hence, queuing capacity of the receiver is MaxCmdSn ExpCmdSn + 1. Status numbering is per connection and is used to enable missing status detection and recovery in the presence of transient or permanent communication errors. Responses in transit from the target to the initiator are numbered. The StatSN (Status Sequence Number) is used for this purpose. StatSN is a counter maintained per connection. The initiator uses ExpStatSN to acknowledge the status to the target. Status numbering starts with the Login response to the first Login request of the connection. The Login response includes an initial value for status numbering (any initial value is valid). To enable command recovery, the target MAY maintain enough state information for data and status recovery after a connection failure. A target doing so can safely discard all of the state information maintained for recovery of a command after the delivery of the status for the command (numbered StatSN) is acknowledged through ExpStatSN. Data sequencing is per command or part of a command (R2T-Ready To Transfer-triggered sequence) and is used to detect missing data and/or R2T PDUs lost due to header digest errors. Fields in the iscsi PDUs are used to communicate the Sequence Numbers between the initiator and target. The iscsi NOP-Out/In PDUs may be utilized to synchronize the command and status ordering counters of the target and initiator when traffic on a connection is unidirectional. The data and R2T PDUs that are transferred as part of some command execution must be sequenced. The DataSN field is used for data sequencing. For input or read data PDUs, DataSN starts with 0 for the first data PDU of an input command and advances by 1 for each subsequent data PDU. For output data PDUs, DataSN starts with 0 for the first data PDU of a sequence (the initial unsolicited sequence or any data PDU sequence issued to satisfy an R2T) and advances by 1 for each subsequent data PDU. R2Ts are also sequenced per command. For example, the first R2T has an R2TSN of 0 and advances by 1 for each subsequent R2T. For bi-directional commands, the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence. Unlike command and status PDUs, data PDUs and R2Ts are not acknowledged in the regular outgoing PDUs. Data-In PDUs are acknowledged on-demand by a special form of the SNACK PDU. The SNACK mechanism is used by the initiator to request the retransmission of numbered-responses, data or R2T PDUs from the target. Data and R2T PDUs are implicitly acknowledged by status for the command. 5

3 Volume 2, Issue 3, June 2013 For these data transfer communications to take place the iscsi targets and the initiators on the network should be identifiable. III. iscsi NAMING AND ADDRESSING For the initiators and targets to identify each other iscsi provides for a naming convention. The initiators and targets must support the receipt of iscsi names that can be maximum 223 bytes long. The initiator should present both the initiator name and name of the target to which it wants to connect to. The iscsi initiator and target names should be globally unique and permanent in the operating domain of the end user. These names do not imply the location or address of the initiator or target. The targets and initiators can have names qualified by iscsi or enterprise specific names. The names in should be unique identifiers of the targets and initiators. The iscsi names are composed of displayable characters that can be transported using both ASCII and binary-based protocols. The iscsi names are logically based and do not depend on any entities that can be changed such as a port or a NIC or HBA on the initiator or target node. The iscsi name is designed to fulfill the functional requirements for Uniform Resource Names. For example, it is required that the name have a global scope, be independent of address or location, and be persistent and globally unique. Names must be extensible and scalable with the use of naming authorities. The name encoding should be both human and machine-readable. An iscsi name should be a UTF-8 encoding of a string of Unicode characters, not more that 223 bytes long. Typically an iscsi target or initiator name consists of two parts-a type designator followed by a unique name string. The type designator can be an iscsi Qualified name (iqu) or Extended Unique Identifier (eui) assigned with the help of some naming authority. The type designators define the structure if name used. The structures for the two designators are as follows. 1. iscsi Qualified Name (iqu): The IQU name consists of the following parts. The string iqu. A date code in yyyy-mm format, specifying the duration during which the domain was owned by the naming authority. A reserved domain name of the naming authority and, The unique name assigned by the authority. The delimiters used in the iscsi name are. (Dots) between the first three parts and : (colon) between the third and fourth part. So typically an iqu assigned name would look like. Type designator Iqu com.eureka: ipsan: lun1234 Figure 2. iqu structure 2. Extended Unique Identifier (eui): The EUI name consists of two parts the eui string and a 64-bit globally unique identifier string provided by the IEEE registration authority. The two parts are separated by a. (dot). So a typical EUI name would look like Type designator Date identifier eui a425678d Figure 2. eui structure IV. iscsi SESSIONS The iscsi specification defines two types of sessions. Discovery sessions: The discovery sessions are used by the initiators to discover targets available on the network. Normal sessions: These are normal data transfer sessions that take place once the full phase starts with the initial logon process. Target Discovery sessions in iscsi Domain Name 64-bit unique identifier string Unique name assigned The initiator needs to discover the targets on a network before it starts communicating with them. The target discovery process is simple in small networks but in a vast network with many targets it may become tedious. Any of the following methods can be used: 1. Manual configuration: The initiator can be manually configured with the target address with the required information for an initiator to start the communication. This method is possible in a small network with less number of targets around. But when the target configuration changes the initiator has to be reconfigured with the new information. 2. SendTargets: In this method the initiator sends a SendTargets command to a target. The target responds with the information about the additional targets it has. But this is a semi-automated approach since the list of available targets has to be configured with the initiator. 6

4 Volume 3, Issue 3, June Service Location Protocol (SLP): A service location protocol helps the initiator to locate the targets in a network. This protocol needs the deployment of a number of agents for target discovery, which makes the process more complex. 4. isns: The Internet Storage Name Service is a new discovery protocol that provides for both naming and storage resource discovery services. The protocol uses a central isns server for tracking the information regarding the targets and initiators in the network. The isns client is implemented at both the initiator and target end. These isns clients register their information with the isns server. The initiator queries with the isns server for the list of targets and initiates the communication based on the information provided by the isns server. The isns servers can be restricted to specific network zones, so that they don t discover targets outside their zone. They also notify the clients about the change in the network. An isns server can be deployed on fibre channel IP as well as regular TCP/IP networks. After successfully discovering a target the initiator starts communicating with the target. The communication starts with the initiator logging into the target. The login establishes a new data transfer session. Normal sessions in iscsi The initiator has to go through a logon process to start a session for transacting or communicating with the iscsi target. The logon process starts as soon as the initiator establishes a TCP/IP socket connection with the target. During the logon process the target and the initiator verify each other s identity through authentication protocols. It also includes negotiation of various session parameters including the data transfer size, security mechanism etc. On successful logon a new full feature session starts, a session id for this session is assigned to both the target and the initiator. Now the phase of data read/write transactions starts and the initiator can now start transferring SCSI commands to the target. After the full feature phase starts an initiator can open multiple unrelated TCP/IP connections for a data transfer for each session, these connections are valid till the session logout doesn t happen. The multiple connections between the initiator target pair can be for communicating SCSI commands, control messages or parameters and data. For any iscsi command issued over a connection the response to it must be sent over the same connection; called connection allegiance. If the connection fails before the response is sent, the connection allegiance should be explicitly reassigned to another connection. Hence for READ requests sent by the initiator, the target should send the data back over the same connection. For WRITE requests sent by the initiator it should send data over the same connection to the target. The R2T and status commands must be ferried back on the same connection on which the corresponding commands were sent. However consecutive commands of a SCSI task can be transferred over different connections. Connection allegiance is per-command and not per task. An iscsi task is a set of linked iscsi commands. Only one command can be pending at the target end for any iscsi task. Each command is tagged at the initiator end using an initiator task tag. This tag helps the target to determine which command the SCSI data packets correspond to. SCSI data sent by the initiator to a target can be solicited data or unsolicited data. Solicited data are sent in response to the R2T PDUs sent by the target to the initiator. Unsolicited data are either sent as part of the command PDUs as immediate data or in different data PDUs. Immediate data are assumed to be at an offset 0 in the SCSI data buffer of the data PDU, all other PDUs explicitly set the buffer offset in the PDU header. An initiator may send unsolicited data up to the negotiated maximum PDU length as immediate and/or as a separate PDU sequence. All the subsequent data must be solicited. The maximum PDU length, immediate data and separate data PDU form of unsolicited data are negotiated during the logon process using FirstBurstLength, ImmediateData and InitialR2T keys respectively. Unsolicited data are used to reduce the effect of latency on the throughput and the immediate data reduce the protocol overheads. Initiator tags are used for the pending SCSI commands; they are unique initiator-wide for a session. Target tags are not strictly specified by the protocol but they are used by the target to tag the solicited data. Target tags are generated by the target and "echoed" by the initiator. These mechanisms help in efficient data delivery; they also provide means for a large degree of control over the data flow. The Initiator Task Tag is used to identify a task during its execution. The iscsi initiator and target must verify that all other fields used in the task related PDUs have values that are consistent with the ones used at the task instantiation based on Initiator Task Tag. For e.g., the LUN used in an R2T PDU MUST be the same as the one used in the SCSI command PDU used to instantiate the task. Using inconsistent field values is considered a protocol error. The integrity of each packet is maintained by the 32-bit CRC checksum called a digest is added in the PDU for end-to-end checking. Moreover TCP/IP layers add their own CRC checksums for packet integrity. Digests are used for both the header to check the data placement and the data. The SCSI task management assumes that individual tasks and task groups can be aborted solely based on: The task tags for individual tasks The timing of the task management command for task groups. Further it assumes that the task management action is executed synchronously so that no message involving an aborted task will be seen by the SCSI initiator after receiving the task management response. 7

5 Volume 2, Issue 3, June 2013 BYTE Basic Header Segment 48 - a Additional Header Segment 1 a - b Additional Header Segment 2 b - c c - d d - e V. Structure of iscsi PDUs The basic iscsi PDU has One basic header segment. One or more additional header segments (optional). The header digest (optional). The data segment (optional). The data digest (optional). The PDU structure is as follows: Header Digest Data Segment Data Digest The basic header segment has a structure as described in the following figure. 0. I Opcode F XXXXXXX 1 Total DataSegmentLength HSLength Logical Unit Number (LUN) or Opcode-Specific fields Fields marked XXXXXXX contain opcode specific data. Given below is the description of the fields. 1. I : The I field is set to 1 for request PDUs as an intermediate delivery marker.opcode: It indicates the type of PDU the header is encapsulating. The opcode can be initiator opcode or a target opcode. The initiator opcodes and the target opcodes are exclusive sets to be used by the initiator and target respectively. The Initiator opcodes are: 0x00 NOP-Out 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block) 0x02 SCSI Task Management function request 0x03 Login Request 0x04 Text Request 0x05 SCSI Data-out (for WRITE operations) 0x06 Logout Request 0x10 SNACK Request 0x1c-0x1e Vendor specific codes The target opcodes are: 2 XXXXXXX Initiator Task Tag (ITT) Opcode Specific Fields 3 XXXXXXX 0x20 NOP-In 0x21 SCSI Response - contains SCSI status and possibly sense information or other response information. 0x22 SCSI Task Management function response 0x23 Login Response 0x24 Text Response 0x25 SCSI Data-in - for READ operations. 0x26 Logout Response 0x31 Ready To Transfer (R2T) - sent by target when it is ready to receive data. 0x32 Asynchronous Message - sent by target to indicate certain special conditions. 0x3c-0x3e Vendor specific codes 0x3f Reject 2. F : The F bit is used to mark the final PDU of a sequence. 3. Opcode specific fields (XXXXXXX): These have different meanings depending on the opcode field. 4. TotalHSLength: Total length of all additional header segments in units of four byte words including padding if any. This field is used only when the PDUs contain Additional headers. 5. DataSegmentLength: This is the length of the data payload within the PDU. This length is excluding any padding used, and is zero whenever there is no data in the PDU. 6. LUN: The LUN field specifies the Logical Unit Number of the logical unit on which the operation specified by the opcode has to be carried out. If it does not related to any logical unit it may be ignored or utilized in an opcode specific way. This field is 64-bit long. 7. InitiatorTaskTag (ITT): This field contains a tag assigned by the initiator to each task. This tag uniquely identifies a task session-wide till the task exists. 8. Opcode specific fields: This field contains information specific to the opcode used. The figure below depicts the iscsi login request PDU. After establishing a TCP connection between an initiator and a target, the initiator must start a Login Phase to gain further access to the target's resources. The Login Phase consists of a sequence of Login requests and responses that carry the same Initiator Task Tag. Login requests are always considered as immediate. 8

6 BYTE ISSN Volume 3, Issue 3, June I 0x03 T C.. CSG NSG Version-max Version-min TotalHSLength DataSegmentLength Connection ID (CID) Initiator Session ID (ISID) Target Session Ident Handle (TSIH) Initiator Task Tag (ITT) Reserved Command Seq. Num. (CmdSN) Reserved [ or Expected Status Seq Num. (ExpStatSN)] to n Reserved Data-Segment -- Text-Login Parameters (key 1 =value, key 2 = value, ) The different fields of the PDU are: 1. T if set to 1 indicates that the initiator is set to transit to the next state. 2. C if set to 1 indicates that the text field in the PDU is incomplete and subsequent PDUs will contain the rest of the data. 3. CSG and NSG stand for current stage and next stage respectively. The valid values are 0 SecurityNegotiation 1 LoginOperationalNegotiation 3 FullFeaturePhase When NSG is set to FullFeaturePhase and T is set to 1 it indicates that the initiator is ready for the final login response. 4. Version-Max and Version-Min stand for the iscsi protocol version. All the login requests must contain the same version number. 5. Initiator Session ID (ISID): This field is the session id assigned by the initiator. This session id is used through out the period that the session exists. 6. Target Session Identity Handle (TSIH): This value is set to zero in the first login request. TSIH is returned by the target in the login response PDU. This value should be used by the initiator in the subsequent request PDUs. This value is a target session identifier. 7. Connection Id (CID): This field uniquely identifies the connection number in the session being initiated. 8. Command Sequence Number (CmdSN): This sequence number is used to streamline the commands in a SCSI task that are sent to the target. 9. Expected Status Number (ExpStatSN): The status number expected from the iscsi target. It is used to acknowledge the login response PDUs. 10. Reserved block. 11. Data Segment: This field contains the data as key=value pairs that are used in the logon process. The keys are such as initiator node name, Target Node Name, Alias Name, Authentication technique, Type of data delivery etc. The figure below depicts the iscsi login response PDU. The login response PDU indicates the progress of the login session. The different fields of the PDU are: 1. The T bit is set to 1 as an indicator of the end of the stage. If the T bit is set to 1 and NSG is FullFeaturePhase, then this is also the Final Login Response. A T bit of 0 indicates a "partial" response, which means, "More negotiation is needed". A login response with a T bit set to 1 will not contain key=value pairs that may require additional answers from the initiator within the same stage. If the status class is 0, the T bit must not be set to 1 if it was set to 0 in the request. 2. The C bit or continue bit when set to 1, indicates that the text in this Login Response is not complete and it will be continued on subsequent Login Responses. If it is set to 0 it indicates that this Login Response ends a set of key=value pairs. A Login Response with the C bit set to 1 must have the T bit set to Version-Max is the maximum protocol version supported by the iscsi target. All login responses will carry the same Version-Max number. 4. Version-Active indicates the highest version supported by the initiator and the target. If the target does not support any version in the range specified by the initiator, then the login request is rejected and this field carries the lowest version number supported by the target. 9

7 Volume 2, Issue 3, June BYTE 0 1. I 0x23 T C.. CSG NSG Version-Max Version-Active Total HSLength DataSegmentLength Initiator Session ID (ISID) Target Session Ident Handle (TSIH) Initiator Task Tag (ITT) Reserved Status Num. (StatSN) Expected Command Seq Num. (ExpCmdSN)] Max Command Seq Num. (MaxCmdSN)] Status-Class Status-Detail Reserved Reserved n Data Segment Login parameters in Text request format. 5. Target Session Identity Handle (TSIH): The TSIH is the target assigned session identifying handle. This handle is returned by the target in the final login response and used by the initiator henceforth. Till the Login Final-Response in a new session, this field should be set to the TSIH provided by the initiator in the Login Request. 6. Status Number (StatSN): For the first Login Response, this is the starting status Sequence Number for the connection. This number is henceforth incremented for all the subsequent responses of any kind, including the next login response. This field is only valid if the Status-Class is Status-Class: The status-class is used by the target to convey the status of the request to the initiator. The value 0 for status-class indicates success and non-zero values indicate error. 1 redirection: indicates that the initiator should take some further steps to complete the login request. 2 Initiator Error: Indicates that the request was not valid. For e.g.: initiator requests for a resource for which it does not have permissions. 3 Target Error: Indicates that the request is valid but the target presently is not capable of serving the request and that initiator may request later. 8. Status-Detail: This field is used to describe the actual error that occurred. 9. Login Parameters: This field contains the response for the values being negotiated by the initiator. The login request and response PDUs were discussed for as examples. Description of rest of the PDUs is not in the scope of this paper and can be found in the RFC specification for iscsi. VI. Error handling and packet recovery in iscsi The iscsi error handling mechanism is needed to handle either the iscsi packet corruption during transit or packet loss due to connection severing during a transaction. Error recovery mechanisms can be decided by the implementations. The standardization of the error recovery mechanism takes into account only the externally visible actions so as to ensure interoperability. The recovery mechanism should take care that both the initiator and target should not initiate the recovery process. Error recovery in iscsi is defined over three different levels: 1. Session recovery: This is to recover from a session failure when all the attempts to recover from an error in a session have failed. This process includes closing all other active TCP connections, aborting all the executing and queued tasks, terminating all the pending SCSI commands with an appropriate SCSI service response to the initiator and restarting the session with a new set of TCP connections. 2. Packet recovery: This is to recover from a packet corruption. The iscsi PDUs may get corrupt or may fail the digest check. In such situations the initiator and target must have a defined way to retransmit such a PDU. 3. Connection recovery: This is to recover from a scenario when a TCP connection pertaining to a session has failed or when all the connections within a session have been dropped. On a connection failure the target closes and removes the connection. It then sends an asynchronous message to the initiator to indicate that it has dropped the 10

8 Volume 3, Issue 3, June 2013 connection and waits for a new connection. The target reassigns the connection allegiance for all commands pertaining to the failed connection, still getting processed, to the new connection from the initiator. The initiator mechanisms defined in connection with error recovery are: 1. NOP-OUT to probe sequence numbers of the target 2. Command retry 3. Recovery R2T support 4. Requesting retransmission of status/data/r2t using the SNACK facility 5. Acknowledging the receipt of the data 6. Reassigning the connection allegiance of a task to a different TCP connection 7. Terminating the entire iscsi session to start afresh The target mechanisms defined in connection with error recovery are: 1. NOP-IN to probe sequence numbers of the initiator 2. Requesting retransmission of data using the recovery R2T feature 3. SNACK support 4. Requesting that parts of read data be acknowledged 5. Allegiance reassignment support 6. Terminating the entire iscsi session to force the initiator to start over VII. SECURITY IN iscsi There are two dimensions to the security concerns in the iscsi protocol. The first is regarding the authentication of the initiator and targets and the second is regarding the safe and secure transfer of data over the TCP/IP channels. The following mechanisms are used by the iscsi implementation for authentication of the iscsi nodes (initiator and target). Challenge Handshake Authentication Protocol (CHAP): The challenge handshake authentication protocol uses secrets that are exchanged between the target and the initiator to authenticate each other during the initial logon phase. CHAP can be one-way or two-way. In one-way CHAP the initiator has to pass on the target secret, so that the target knows the initiator is an authentic one. In two-way or mutual CHAP, once the initiator has sent the target secret the target has to revert back with the initiator secret to authenticate itself with the initiator. SRP (Secure Remote Password): Any secure remote password protocol may be used for authentication of the iscsi initiators and targets. For the secure transfer of data across the TCP/IP channels IPSec comes into play. IP Security (IPSec): iscsi uses the IPsec mechanism for packet protection using cryptographic integrity, authentication, and confidentiality at the IP level between the iscsi communicating nodes. The IPsec protocols must be implemented for data integrity and authentication, confidentiality, and cryptographic key management. An iscsi initiator or target may provide the required IPsec support fully integrated or in conjunction with an IPsec front-end device. VIII. CONCLUSION IP Storage protocols will make possible to use effectively storage area networks in those applications for which the Fibre Communication cannot provide an effective realization. With the FCIP and ifcp protocols data storage networks will be geographically distributed. And the iscsi will make possible to use advantages of the SAN in the spheres that are still not or ineffectively realized within popular technologies. IX. TERMS AND ABBREVIATIONS SAN - Storage Area Network CDB - command descriptor block. PDU - Protocol Data Unit. SNIA - Storage Networking Industry Association. iscsi - Internet Small Computer Systems Interface isns - Internet Storage Name Service X. REFERENCES [1]RFC 3720 Satran, Julian; Kalman, Meth; Sapuntzakis, Costa; Zeidner, Efri; Chadalapaka, Mallikarjun ( ). [2] iscsi Version 2.0 rev 15 SNIA, June 30, [3]Microsoft Storage Technologies iscsi, [4]Architecture and Dependability of Large-Scale Internet Services David Oppenheimer and David A. Patterson, Berkley, IEEE Internet Computing, September October [5]Information technology - iscsi Management API Version 1.1.6, ANSI. [6]A Not So Short iscsi Tutorial, HPCL, University of Rhode Island 10/03. [7] IP storage: A review of iscsi, FCIP, ifcp, Jane Shurteff, iscsi Storage. [8] Fibre Channel SANs vs. iscsi, Computer Technology Review, March, 2004 by Steve Klotz [9] ISCSI vs. Fibre Channel Explained: ISCSI takes its rightful place beside Fibre Channel, 13 Jul 2007, Stephen J. Bigelow. [10] iscsi vs. Fibre Channel by Alan Zeichick, 24 Jul Manuscript received July 25, Sandeep Gupta, Apache Technologies Pvt. Ltd., ( sg@apachetechnology.in). Kanpur, India,