Download iSCSI – A Revolutionary IP based SAN

ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
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.
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.
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.
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.
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.
iSCSI Initiator Node
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
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.
iSCSI Target Node
Application
Logical Unit
SCSI Driver
SCSI Driver
iSCSI Protocol
iSCSI Protocol
TCP/IP Layer
TCP/IP Layer
Ethernet
Ethernet
Index Terms – SAN, iSCSI, PDU, TCP/IP, HBA, LUN, CBD
I. AN INTRODUCTION TO iSCSI
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.
Physical communication medium
Figure 1: iSCSI Protocol Stack
4
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
Volume 3, Issue 3, June 2013
The command sequence number is not incremented if the
The applications at the iSCSI initiator end makes the data command is marked for immediate delivery. The iSCSI
transfer requests; the SCSI driver converts these requests into commands in a task are executed as per their sequence
Command Description blocks or CDBs. These CDBs are then numbers.
passed on to the iSCSI layer, which encapsulates the CDBs The command sequencing is implemented using three fields
into Protocol Data Units or PDUs. The PDUs at the iSCSI in the PDU:
layer carry information regarding the specific target such the  CmdSn: The current sequence number.
logical unit number of the destination device. The iSCSI layer  ExpCmdSn: The next command expected by the target. The
PDU then goes down the TCP/IP stack where each layer adds
target will acknowledge all the commands with CmdSn
additional information in the respective headers. This packet
lower than ExpCmdSn value.
is then transported to the target end over the network  MaxCmdSn: Maximum number of commands that can be
infrastructure. The figure below depicts the SCSI command
shipped. Hence, queuing capacity of the receiver is
encapsulation.
MaxCmdSn – ExpCmdSn + 1.
Status numbering is per connection and is used to enable
missing status detection and recovery in the presence of
IP
TCP
iSCSI
SCSI command packet
Header
Header
Header
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.
Figure 2. SCSI commands encapsulation
StatSN is a counter maintained per connection. The initiator
uses ExpStatSN to acknowledge the status to the target. Status
During the write request from the applications at the initiator numbering starts with the Login response to the first Login
end the SCSI commands are encapsulated at the initiator end, request of the connection. The Login response includes an
and for the read requests the commands are encapsulated at initial value for status numbering (any initial value is valid).
the target end. PDUs are also defined for controlling the flow To enable command recovery, the target MAY maintain
of data and target responses.
enough state information for data and status recovery after a
Communication between the initiator and target occurs over connection failure. A target doing so can safely discard all of
one or more TCP connections. The TCP connections carry the state information maintained for recovery of a command
control messages, SCSI commands, parameters, and data after the delivery of the status for the command (numbered
within iSCSI Protocol Data Units (iSCSI PDUs). The group StatSN) is acknowledged through ExpStatSN.
of TCP connections that link an initiator with a target form a Data sequencing is per command or part of a command
session. A session is defined by a session ID that is composed (R2T-Ready To Transfer-triggered sequence) and is used to
of an initiator part and a target part. TCP connections can be detect missing data and/or R2T PDUs lost due to header
added and removed from a session. Each connection within a digest errors. Fields in the iSCSI PDUs are used to
session is identified by a connection ID (CID).
communicate the Sequence Numbers between the initiator
and target. The iSCSI NOP-Out/In PDUs may be utilized to
Across all connections within a session, an initiator sees one synchronize the command and status ordering counters of the
"Target Image". All target-identifying elements, such as target and initiator when traffic on a connection is
LUN, are same. A target also sees one "initiator image" across unidirectional. The data and R2T PDUs that are transferred as
all connections within a session. Initiator identifying part of some command execution must be sequenced. The
elements, such as the Initiator Task Tag, are global across the DataSN field is used for data sequencing. For input or read
session regardless of the connection on which they are sent or data PDUs, DataSN starts with 0 for the first data PDU of an
received.
input command and advances by 1 for each subsequent data
PDU. For output data PDUs, DataSN starts with 0 for the first
iSCSI uses Command and Status numbering schemes and a data PDU of a sequence (the initial unsolicited sequence or
Data sequencing scheme. Command numbering is any data PDU sequence issued to satisfy an R2T) and
session-wide and is used for ordered command delivery over advances by 1 for each subsequent data PDU. R2Ts are also
multiple connections. It can also be used as a mechanism for sequenced per command. For example, the first R2T has an
command flow control over a session. iSCSI performs R2TSN of 0 and advances by 1 for each subsequent R2T. For
ordered command delivery within a session. All commands bi-directional commands, the target uses the DataSN/R2TSN
(initiator-to-target PDUs) in transit from the initiator to the to sequence Data-In and R2T PDUs in one continuous
target are numbered. iSCSI considers a task to be instantiated sequence. Unlike command and status PDUs, data PDUs and
on the target in response to every request issued by the R2Ts are not acknowledged in the regular outgoing PDUs.
initiator and each task is identified by the Initiator task tag as Data-In PDUs are acknowledged on-demand by a special
long as the task is valid. The command sequence number is form of the SNACK PDU. The SNACK mechanism is used
carried in the iSCSI PDU in the CmdSn field. The numbering by the initiator to request the retransmission of
is session-wide and all the outgoing iSCSI PDUs carry this numbered-responses, data or R2T PDUs from the target. Data
sequence number. Command sequencing starts with the first and R2T PDUs are implicitly acknowledged by status for the
login request in the first session, then on the command command.
sequence number is incremented.
5
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
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.
Iqu.2004-06.com.eureka: ipsan: lun1234
Type
designator
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.
Date
identifier
Domain
Name
Unique
name
assigned
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
eui.02004567A425678D
Type
designator
64-bit unique
identifier string
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
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
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
Volume 3, Issue 3, June 2013
3. Service Location Protocol (SLP): A service location However consecutive commands of a SCSI task can be
protocol helps the initiator to locate the targets in a transferred over different connections. Connection allegiance
network. This protocol needs the deployment of a is per-command and not per task. An iSCSI task is a set of
number of agents for target discovery, which makes the linked iSCSI commands. Only one command can be pending
process more complex.
at the target end for any iSCSI task. Each command is tagged
4. iSNS: The Internet Storage Name Service is a new at the initiator end using an initiator task tag. This tag helps
discovery protocol that provides for both naming and the target to determine which command the SCSI data packets
storage resource discovery services. The protocol uses a correspond to.
central iSNS server for tracking the information SCSI data sent by the initiator to a target can be solicited data
regarding the targets and initiators in the network. The or unsolicited data. Solicited data are sent in response to the
iSNS client is implemented at both the initiator and target R2T PDUs sent by the target to the initiator. Unsolicited data
end. These iSNS clients register their information with are either sent as part of the command PDUs as immediate
the iSNS server. The initiator queries with the iSNS data or in different data PDUs.
server for the list of targets and initiates the Immediate data are assumed to be at an offset 0 in the SCSI
communication based on the information provided by the data buffer of the data PDU, all other PDUs explicitly set the
iSNS server. The iSNS servers can be restricted to buffer offset in the PDU header. An initiator may send
specific network zones, so that they don’t discover unsolicited data up to the negotiated maximum PDU length as
targets outside their zone. They also notify the clients immediate and/or as a separate PDU sequence. All the
about the change in the network. An iSNS server can be subsequent data must be solicited. The maximum PDU length,
deployed on fibre channel IP as well as regular TCP/IP immediate data and separate data PDU form of unsolicited
networks.
data are negotiated during the logon process using
FirstBurstLength, ImmediateData and InitialR2T keys
After successfully discovering a target the initiator starts respectively. Unsolicited data are used to reduce the effect of
communicating with the target. The communication starts latency on the throughput and the immediate data reduce the
with the initiator logging into the target. The login establishes protocol overheads.
a new data transfer session.
Initiator tags are used for the pending SCSI commands; they
are unique initiator-wide for a session. Target tags are not
Normal sessions in iSCSI
strictly specified by the protocol but they are used by the
The initiator has to go through a logon process to start a target to tag the solicited data. Target tags are generated by
session for transacting or communicating with the iSCSI the target and "echoed" by the initiator. These mechanisms
target. The logon process starts as soon as the initiator help in efficient data delivery; they also provide means for a
establishes a TCP/IP socket connection with the target. large degree of control over the data flow. The Initiator Task
During the logon process the target and the initiator verify Tag is used to identify a task during its execution. The iSCSI
each other’s identity through authentication protocols. It also initiator and target must verify that all other fields used in the
includes negotiation of various session parameters including task related PDUs have values that are consistent with the
the data transfer size, security mechanism etc. On successful ones used at the task instantiation based on Initiator Task Tag.
logon a new full feature session starts, a session id for this For e.g., the LUN used in an R2T PDU MUST be the same as
session is assigned to both the target and the initiator. Now the the one used in the SCSI command PDU used to instantiate
phase of data read/write transactions starts and the initiator the task. Using inconsistent field values is considered a
can now start transferring SCSI commands to the target.
protocol error.
After the full feature phase starts an initiator can open The integrity of each packet is maintained by the 32-bit CRC
multiple unrelated TCP/IP connections for a data transfer for checksum called a digest is added in the PDU for end-to-end
each session, these connections are valid till the session checking. Moreover TCP/IP layers add their own CRC
logout doesn’t happen. The multiple connections between the checksums for packet integrity. Digests are used for both the
initiator target pair can be for communicating SCSI header to check the data placement and the data.
commands, control messages or parameters and data.
The SCSI task management assumes that individual tasks and
For any iSCSI command issued over a connection the task groups can be aborted solely based on:
response to it must be sent over the same connection; called  The task tags for individual tasks
connection allegiance. If the connection fails before the  The timing of the task management command for task
response is sent, the connection allegiance should be
groups.
explicitly reassigned to another connection. Hence for READ Further it assumes that the task management action is
requests sent by the initiator, the target should send the data executed synchronously so that no message involving an
back over the same connection. For WRITE requests sent by aborted task will be seen by the SCSI initiator after receiving
the initiator it should send data over the same connection to the task management response.
the target. The R2T and status commands must be ferried back
on the same connection on which the corresponding
commands were sent.
7
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
Volume 2, Issue 3, June 2013
V. Structure of iSCSI PDUs
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 Bit: 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.
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:
0 - 48
Basic Header Segment
48 - a
Additional Header Segment 1
a-b
Additional Header Segment 2
b-c
Header Digest
c-d
Data Segment
d-e
Data Digest
The basic header segment has a structure as described in the
following figure.
BYTE
00 -- 03
04 -- 07
08 -- 15
0
1
2
3
Bit
76543210
Bit
76543210
Bit
76543210
Bit
76543210
. I Opcode
F
XXXXXXX
XXXXXXX
XXXXXXX
Total
DataSegmentLength
HSLength
Logical Unit Number (LUN) or Opcode-Specific fields
16 -- 19
Initiator Task Tag (ITT)
20 -- 48
Opcode Specific Fields
Fields marked XXXXXXX contain opcode specific data.
Given below is the description of the fields.
1. I Bit: 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:
8
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
Volume 3, Issue 3, June 2013
0
BYTE
00 -- 03
04 -- 07
1
Bit
76543210
Bit
7654 32 10
. I
T C . . CSG NSG
0x03
TotalHSLength
2
3
Bit
76543210
Bit
76543210
Version-max
Version-min
DataSegmentLength
08
Initiator Session ID (ISID)
Target Session Ident Handle (TSIH)
-- 15
16 -- 19
Initiator Task Tag (ITT)
20 -- 23
Connection ID (CID)
Reserved
24 -- 27
Command Seq. Num. (CmdSN)
28 -- 31
Reserved [ or Expected Status Seq Num. (ExpStatSN)]
32 -- 47
Reserved
48 to n
Data-Segment -- Text-Login Parameters
(key1=value, key2 = 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 0.
3. 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
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
Volume 2, Issue 3, June 2013
0
BYTE
00 -- 03
04 -- 07
2
3
Bit
76543210
Bit
7654 32 10
Bit
76543210
Bit
76543210
. I
T C . . CSG NSG
Version-Max
Version-Active
0x23
1
Total HSLength
DataSegmentLength
08
Initiator Session ID (ISID)
-- 15
Target Session Ident Handle (TSIH)
16 -- 19
Initiator Task Tag (ITT)
20 -- 23
Reserved
24 -- 27
Status Num. (StatSN)
28 -- 31
Expected Command Seq Num. (ExpCmdSN)]
32 -- 35
Max Command Seq Num. (MaxCmdSN)]
36 -- 39
Status-Class
Status-Detail
Reserved
40 -- 47
Reserved
48 -- 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 0.
7. 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.
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
The login request and response PDUs were discussed for as
examples. Description of rest of the PDUs is not in the scope
10
ISSN 2249-6343
International Journal of Computer Technology and Electronics Engineering (IJCTEE)
Volume 3, Issue 3, June 2013
connection and waits for a new connection. The target
VIII. CONCLUSION
reassigns the connection allegiance for all commands
pertaining to the failed connection, still getting IP Storage protocols will make possible to use effectively
storage area networks in those applications for which the
processed, to the new connection from the initiator.
The initiator mechanisms defined in connection with error Fibre Communication cannot provide an effective realization.
With the FCIP and iFCP protocols data storage networks will
recovery are:
be geographically distributed. And the iSCSI will make
1. NOP-OUT to probe sequence numbers of the target
possible to use advantages of the SAN in the spheres that are
2. Command retry
still not or ineffectively realized within popular technologies.
3. Recovery R2T support
4. Requesting retransmission of status/data/R2T using the
SNACK facility
IX. TERMS AND ABBREVIATIONS
5. Acknowledging the receipt of the data
6. Reassigning the connection allegiance of a task to a SAN - Storage Area Network
CDB - command descriptor block.
different TCP connection
PDU - Protocol Data Unit.
7. Terminating the entire iSCSI session to start afresh
The target mechanisms defined in connection with error SNIA - Storage Networking Industry Association.
iSCSI - Internet Small Computer Systems Interface
recovery are:
iSNS - Internet Storage Name Service
1. NOP-IN to probe sequence numbers of the initiator
2. Requesting retransmission of data using the recovery R2T
X. REFERENCES
feature
3. SNACK support
[1]RFC 3720 Satran, Julian; Kalman, Meth; Sapuntzakis,
4. Requesting that parts of read data be acknowledged
Costa; Zeidner, Efri; Chadalapaka, Mallikarjun
5. Allegiance reassignment support
(2004-04-02).
6. Terminating the entire iSCSI session to force the initiator to
[2] iSCSI Version 2.0 rev 15 SNIA, June 30, 2008.
start over
[3]Microsoft Storage Technologies – iSCSI, 2003.
[4]Architecture and Dependability of Large-Scale Internet
VII. SECURITY IN iSCSI
Services David Oppenheimer and David A. Patterson,
Berkley, IEEE Internet Computing, September–October
There are two dimensions to the security concerns in the
2002.
iSCSI protocol. The first is regarding the authentication of the
initiator and targets and the second is regarding the safe and [5]Information technology - iSCSI Management API Version
1.1.6, ANSI.
secure transfer of data over the TCP/IP channels. The
following mechanisms are used by the iSCSI implementation [6]A Not So Short iSCSI Tutorial, HPCL, University of
Rhode Island 10/03.
for authentication of the iSCSI nodes (initiator and target).
Challenge Handshake Authentication Protocol (CHAP): The [7] IP storage: A review of iSCSI, FCIP, iFCP, Jane Shurteff,
iSCSI Storage.
challenge handshake authentication protocol uses secrets that
are exchanged between the target and the initiator to [8] Fibre Channel SANs vs. iSCSI, Computer Technology
Review, March, 2004 by Steve Klotz
authenticate each other during the initial logon phase. CHAP
can be one-way or two-way. In one-way CHAP the initiator [9] ISCSI vs. Fibre Channel Explained: ISCSI takes its
rightful place beside Fibre Channel, 13 Jul 2007, Stephen J.
has to pass on the target secret, so that the target knows the
Bigelow.
initiator is an authentic one. In two-way or mutual CHAP,
once the initiator has sent the target secret the target has to [10] iSCSI vs. Fibre Channel by Alan Zeichick, 24 Jul 2001.
revert back with the initiator secret to authenticate itself with
the initiator.
Manuscript received July 25, 2013.
SRP (Secure Remote Password): Any secure remote
Sandeep Gupta, Apache Technologies Pvt. Ltd., (e-mail:
password protocol may be used for authentication of the [email protected]). Kanpur, India, +91 8130210999.
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.
11