iscsi intro
Post on 09-Apr-2018
221 Views
Preview:
TRANSCRIPT
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 1/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 1 of 15
White Paper
Introduction to iSCSI
Executive Summ ary
This white paper p rovides a basic working
knowledge of the Internet Small Computer
Systems Interface (iSCSI) protocol. iSCSI is
an SCSI transport protocol for mapping of
block-oriented storage data over TCP/IP
networks. The paper focuses primarily on
iSCSI, therefore some background in SCSIand storage-area network (SAN) protocols
and architectures is recommended.
Additional white papers that cover these
other areas are referenced at the end of this
document.
Information on the iSCSI protocol provided
in this document is based on the Internet
Engineering Task Force (IETF) IP Storage
(IPS) iSCSI draft 10. For additional details,
this document can be referenced via the
URL provided in the referencesat the end of
the document.
This paper includes a breakdown o f the
iSCSI protocol and processes, iSCSI
security and management considerations,
and some basic implementation
information. Additionally, t erms and
acronyms are defined as they pertain to
the iSCSI protocol.
iSCSI in Perspective
Basic Concept of iSCSI
Conceptually, iSCSI+TCP+IP provide an
equivalent of Layer3/4 network transpor t,
rather than alternatives of either parallel
SCSI cableor Fibre Channel Protocol (FCP)
(SCSI over Fibre Channel). The basic idea
of iSCSI is to take advantage of the
investment in existing IP networks to
facilitate and extend SANs. This is
accomplished by using the TCP/IP protocol
to transport SCSI commands and data
between host and SAN nodes.
Traditionally SANs have required a
separate dedicated infrastructure to
interconnect hosts and storage systems. The
primary means for t hese interconnections
are Fibre Channel networks that providethe SCSI transpor t. The result is that
separate para llel networks have to be built
to suppor t IP applications and a ssociated
storage. Additionally, Fibre Channelcannot
be transported over lower-bandwidth WAN
networks in its nat ive form, therefore
requires special hardware and handling.
The use of iSCSI over IP networks does not
necessarilyreplace a Fibre Channelnetwork
but rather provides a transport for an
IP-attached host to reach FibreChannel-based SANs.
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 2/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 2 of 15
IP network infrastructures provide major advantages for interconnection of servers to block-oriented storage devices.
IP networks are cost-effective, and they provide security, scalability, interoperability, network management, and
storage management.
IP network advantages include:
• IPnetworksoffer the availability of network protocols and middlewarefor management, security, and quality of
service (QoS).
• Skills developed in the design and mana gement of IP networks can be applied to IP SANs. Trained and
experienced IP networking staffs are available to install and operate t hese networks.
• IP networks offer economies achieved from using a standar d IP infrastructure, products, and service across
the organization.
• iSCSI is compatible with existing IP LAN and WAN infrastructures.
• Distance is limited to application timeout, not by IP networks.
Value of iSCSI
By building on existing IP networks, users can connect hosts to storage facilities without additional host adapt ers,
better utilize storageresources, and eliminate the need for separate parallel WAN infrastructures. Because iSCSI uses
TCP/IP as its transport for SCSI, information can be passed over existing IP-based host connections typically via
Ethernet. Additional valuecan be realized by beingable to better utilize existing storage resources. Because hosts can
utilize their existing IP/Ethernet network connection to access storage elements, it is now easier to consolidate storage
and, therefore, realize higher utilization. As mentioned previously, SANs have in the past required special provisions
for WAN connectivity. Significant cost savings can be realized by utilizing existing WAN connections for hosts to
access storage via IP.
Other IP SAN Protocols
It should be noted that there are other proposed dra fts for transport ing storage traffic over IP networks. These
include Fibre Channel over IP (FCIP), Internet Fibre Channel (iFCP), and Internet Storage Name Service (iSNS).
Although these protocols are outside the scope of this document; additional information on them can be found in
the references.
iSCSI Standards Track
The iSCSI draft isone of several protocols being worked on by the IPStorage(IPS) , working group in the IETF. Many
industry leaders such as Cisco, IBM, and HP are leading the effort of standardizing the draft. The current release is
draft-ietf-ips-iscsi-14 da ted July 1, 2002. It is anticipated that t he iSCSI draft will be submitted to the Internet
Engineering Steering Group (IESG) for consideration as pr oposed standards later this year. N umerous vendors arecurrently developing products to the current draft standard. When setting up prestandard iSCSI solutions, it is
necessary to determine which draft a vendor’s product(s) is based on in order to achieve interoperability.
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 3/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 3 of 15
Fundament als of iSCSI
This section discusses the various layers and processes of iSCSI in order to build an overall functional understanding.Therefore, detailed packet formats and structures are intentionally omitted. This section focuses on iSCSI specifically,
and the transport of SCSI over IP. However, a brief discussion of SCSI architecture is provided to aid in the
understanding of this document.
SCSI Architecture
SCSI stands for Small Computer Systems Interface. Itsroot can be traced back to Shugart AssociatesSystem Interface
(SASI), a disk drive and controller manufacturer. Based on the IBM input/output (I/O) channel, the SASI interface
was widely received. It was introduced in 1979, when only an 8-bit parallel interface was available. The basic use of
SASI was to allow independent peripheral devices to be connected to small and medium-sized computers.
In 1982, a formal draft of SCSI based on SASI was developed. Additional capacities were added to make this draft
the first generation of the SCSI standard. The new capabilities include peer-to-peer communication, logical units,
arbitration, and so on.
The American National Standards Institute (ANSI) approved SCSI-2 in 1994. It is a complete standalone document
with the expanded definition of the Common Command Set (CCS) providing a software interface to many
peripherals in addition to all disk drives. SCSI-2 defines the differential interface and the 16- and 32-bit-wide data
bus, essentially doubling data throughput. It is backward compatible to SCSI-1.
SCSI-3 standards are currently under development. SCSI-3 refers to a collection of standards as a result of breaking
SCSI-2 into smaller, hierarchical modules that fit within a general framework called SCSI Architecture Model (SAM)
(refer to Figure 1).
Figure 1
SCSI Architecture M odel and SCSI-3 Standards
SAM defines the concepts, entities, and interactions of SCSI layers. It mandates the initiator and target entities in the
client/server model. The interaction between the initiator and ta rget allows the information about t he initiator and
the target to be exchanged (refer to Figure 2). An example of such information is logical unit number (LUN).
Common Access Method CAM ASPI Generic
SCSI Device-Type Specif ic Command Sets SBC SSC SES More
Shared Command Set (for all SCSI Device Types) SPC-2/SPC-3
ATAPI iSCSISPI-x
FCP
FC-xx
SBP
1394
Transport Protocols
Physical Interconnects A r c h i t e c t u r e M
o d e l
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 4/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 4 of 15
Figure 2
SCSI Initiator and Target Interaction
The SAM defines genericrequirements and implementation requirements. A servicerequest must include a command
descriptor block (CDB), a basic building block for SCSI information exchange. Figure 3 shows the format of a CDB.
Figure 3
SCSI Command Descriptor Block (CDB)
iSCSI Terminology
The iSCSI draft uses the concept of a “network entity,” which represents a device or gateway that is attached to an
IP network. This network entity must conta in one or more network porta ls. An iSCSI node contained within a
network entity can utilize any of the network portals to access the IP network. The iSCSI node is an iSCSI initiator
or target identified by its iSCSI name within a network entity. A SCSI device, as defined by SAM, is the iSCSI name
of the node. There is exactly one SCSI device within an iSCSI node.
A network porta l is essentially the component within t he network entity responsible for implementing the TCP/IP
protocol stack. Relative to the initiator, the network portal is identified solely by its IP address. For an iSCSI target,
its IP address and its TCP listening port identify the network portal. Refer to Figure 4 for components within iSCSI
client and iSCSI server. For iSCSI communications, a connection is established between an initiator network portal
and a target network porta l. A group of TCP connections between an initiator iSCSI node and a target iSCSI node
make up an iSCSI session. This is analogous to but not equal to the SCSI I_T Nexus.
Application
Client
Initiator Target
Device Service Response
Device Service RequestDevice
Server
Logical Unit
Task
ManagerTask M anagement Response
Task M anagement Request
Control Byte
Transfer Length
Logical Bloc k Address
Operation Code
Bit 1 Bit 0Bit 2Bit 3Bit 4Bit 5Bit 6Bit 7
0
1
2
3
4
5
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 5/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 5 of 15
Figure 4
Components within iSCSI Client and iSCSI Server
Also defined by the standard draft are por tal groups. Because iSCSI supports multiple TCP connections within a
session, it is possible that these connections could be across multiple network portals. Therefore, a portal group is a
set of network porta ls that suppor ts an iSCSI session that is made up o f multiple connections over different
network portals.
Naming and Addressing
The iSCSI protocol enables a methodology for both the naming and addressing of iSCSI initiators and targets. All
iSCSI nodes, initiators, and targets are known by their iSCSI name. This isnot to be confused with a host-type name
that is resolved into an IP address, nor is it a worldwide node name. Therefore, this name is independent of the node
location. There are two iSCSI name formats, iqn (iSCSI qualifier name)format and IEEEEUI format. An example of
an iSCSI name with iqn forma t is: iqn.1987-05.com.Cisco.00.9f9ccf185aa2508c7a168967ccf96e0c.target1.
An iSCSI name is useful because it provides:
• A method for multiple initiators or targets to share a common IP network address
• A method for multiple initiators or tar gets to be accessed via multiple IP addresses
• A means by which nodes can be known, independent of their IP address and irrespective of the presence of IP
address and port mapping on firewalls
The iSCSI protocol does not do any processing of the iSCSI name other than to perform case-sensitive
matching operations.
The iSCSI initiator name is the unique worldwide name this initiator is known by. Likewise, the iSCSI target name
specifies the unique worldwide name of the target. These names in part can be used to identify the SCSI I_T Nexus
as defined by SAM.
iSCSI Node
(iscsi Initiator)
Netw ork Entity (iSCSI Server)
Netw ork Entity (iSCSI Client)
Network Portal
10.1.1.1
Network Portal
10.1.2.1
Network Portal
10.1.1.2 and tc p port 3260
Network Portal
10.1.2.2 and tcp port 3260
iSCSI Node
(iscsi Target)
iSCSI Node
(iscsi Target)
IP Network
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 6/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 6 of 15
Addressing of an iSCSI node conforms to the standards-based IP addressing schema of <domain-name>[:port]. The
<domain-name> can be of the form of either an IPv4 address in dot ted-decimal notation, an IPv6 address in
colon-separated hexadecimal nota tion, or a fully qualified domain name.
For iSCSI targets, the po rt number may also be specified along with the add ress. If no port is provided, the default
port 3260 as assigned by the Internet Assigned Num bers Authority (IANA) is assumed.
iSCSI Protocol
The iSCSI protocol is a mapping of the SCSI Remote Procedure Call (reference SAM) model to the TCP/IP protocol.
The iSCSI protocol provides its own conceptual layer independent of the SCSI CDB information it carries. In this
fashion, SCSI commands are transported by iSCSI request and SCSI response and status are handled by iSCSI
responses. Also, iSCSI protocol tasks are carried by this same iSCSI request and response mechanism (refer to
Figure 5).
Figure 5
iSCSI Protocol Stack
Just as in the SCSI protocol, iSCSI employsthe concepts of “initiator,” “target,” and communication messages called
protocol data units (PDUs). Likewise, iSCSI transfer direction is defined respective to the initiator. As a means to
improve performance, iSCSI allows a “ phase collapse” t hat a llows a command or r esponse and its associated data
to be sent in a single iSCSI PDU.
iSCSI Session
The highest level of an iSCSI communications path is a session that is formed between an iSCSI initiator and an iSCSI
target. There are two types of sessions defined in iSCSI, a normal operational session and a discovery session used by
the initiator to discover available targets.
A session is identified by a session ID (SSID), which is made up of an initiator (ISID) and target (TSID) components.
TCP connections may be added and removed within a session; however, allconnections are between the same unique
initiator and target iSCSI nodes. Each connection within a session has a unique connection ID (CID). The makeup
of the SSID, ISID, TSID, and CID are examined in greater detail later in this document (refer to Figure 6).
iSCS— SCSI over TCP/IP
TCP
IP
SCSI Appl ications (File Systems, Databases)
SCSI Block SCSI Command Other SCSI
SCSI Commands, Data, and Status
Ethernet, etc.
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 7/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 7 of 15
Figure 6
iSCSI Sessions wit h One or M ultiple Connections
An iSCSI session is established via the iSCSI login process. This session is used t o ident ify all TCP connections
associated with a par ticular SCSI I_T Nexus. There may be one or more TCP connections within one session.
The login process is started when the initiator establishes a TCP connection to the desired target either via the
well-known por t or a specified target port . The initiator and target may carry out authentication of each other and
negotiate a security protocol. During the login phase, numerous attributes are negotiated between the iSCSI initiator
and the iSCSI target.
Upon the successful completion of the login phase, the session enters “full feature phase.” Login and security are
further add ressed later in this document.
iSCSI Sequencing
The iSCSI protocol deploys several registers to maintain ordering and sequencing of commands, statu s, and data.
Each of these registers is an unsigned 32-bit integer counter. These numbers are communicated between the initiator
and target in t he appr opriate iSCSI PDU fields dur ing command, stat us, and data exchanges. Additionally, an
initiator or target may utilize a NO P-OUT/IN PDU to synchronize sequencing and numbering registers.
Comm and N umbering
Within an iSCSI session, all commands (initiator-to-target PDUs) are numbered with a command sequence number
(CmdSN). CmdSN isused to ensurethat everycommand isdelivered in the order it istransmitted, regardless of which
TCP connection in one session the command is carried on.
Command sequencing begins with the first login command and is incremenated by on r for each subsequent
command. It is the responsibility of the iSCSI target layer to deliver the commands to the SCSI layer in the order of
their CmdSN. The one exception t o this is a command marked for immediate delivery. In this case, the CmdSN is
not incremented and the iSCSI target passes this command to the SCSI layer as soon as it is detected.
In addition to the CmdSN, the initiator and target maintain an expected command register (ExpCmdSN) and a
maximum command register (MaxCmdSN). The target sets the ExpCmdSN to the highest-numbered nonimmediate
command CmdSN it can deliver to the SCSI layer plus one. This acknowledges to the initiator the last in-sequence
command received by the target. Because commandsmay be sent over multipleTCP connections, the target may have
commands queued with a CmdSN higher than ExpCmdSN. These commands are held in order to pr event
out-of-sequence commands from being handed off to the SCSI layer. The MaxCmdSN is used by the initiator to
determine if the target has queue space for additional commands to be sent. The queue capacity is derived by
MaxCmdSN – ExpCmdSN + 1.
iSCSI
Initiator
iSCSI HostiSCSI Session
iSCSI Session
iSCSI Device
TCP Connection
TCP Connection
TCP Connection
iSCSI Target
iSCSI Target
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 8/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 8 of 15
Status Num bering
Similarly to command numbering, status responses are sequentially numbered with a status sequence number(StatSN). Likewise, the initiator uses an expected status sequence number (ExpStatSN) register to acknowledge status
PDUs received from the target. The initiator initiates recovery actions if the difference between the StatSN and
ExpStatSN exceeds a preset value.
Data Sequencing
Data and request-to-transfer (R2T) PDUs are sequenced using the DataSN and R2TSN registers, respectfully. Data
sequencing is used t o ensure the in-order delivery of dat a within the same command.
For Read operations, theDataSN begins at 0 and isincremented by 1 for each subsequent data PDU in that command
sequence. In the caseof a write, the first unsolicited data PDU or the first data PDU in responseto a R2T begins with
a DataSN of 0 and incrementsby 1 for each subsequent data PDU. R2TSN is set to 0 at theinitiation of thecommand
and incremented by 1 for each subsequent R2T sent by the target for that command.
iSCSI PDU s
The TCP payload of an iSCSI packet contains iSCSI PDUs. All iSCSI PDUs begin with one or more header segments
followed by zero or one data segment.
The first segment is the basic header segment (BHS), a fixed-length 48-byte header segment. Additional header
segments (AHSs) may follow the BHS. Figure 7 shows the format and content of an iSCSI PDU. All the headers are
optional except BHS. The figure shows the iSCSI packet format with iSCSI PDU in the TCP payload.
Figure 7
iSCSI Packet Format
Options and Padding
TCP Header
Offset Reserved U A P R S F
Checksum Urgent Pointer
Window
Acknowledgement Number
Sequence Number
Data-Digest
Data Segment
Header-Digest
Additional Header Segment (AHS)
Basic Header Segment (BHS)
Sourced Port
3260 iSCSI
Well-known Ports:
21 FTP
23 Telnet
25 SMTP
80 http
Destination Port
PreambleDestination
Address
Source
AddressType IP TCP
46–1500 Bytes
Data FCS
8 6 6 2 4 Octet
iSCSI PDU
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 9/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 9 of 15
iSCSI PDUtypes include iSCSI request and respond, text request and respond, login request and respond, and so on.
Figure 8 shows an example of the header forma t for one of the iSCSI request commands.
Figure 8
iSCSI PDU Command
iSCSI Error Handling
A fundamental portion of error r ecovery is maintaining enough state and dat a to recover an errant pr ocess. This is
the casewith iSCSI in that the initiator isexpected to retain the necessary command and data information to be able
to rebuild any outstanding PDU. Likewise, the target is expected to maintain any unacknowledged da ta-out a long
with status response information.
Two mechanisms used by iSCSI for error handling are retry and reassignment. An initiator may at tempt to “plug”
any missing CmdSN by resending the same command or data PDU to the target. The reassignment is used when the
TCP connection between the initiator and the target is lost. In this case, the initiator sends a “Task Reassign” task
management PDUvia a new connection, instructingthe target to continue an outstanding command on the new CID.
It is not required for targets to support this feature, which is negotiated at login time.
iSCSI Process
This section explains a completeiSCSI connection setup, exchange, and termination. Many variations can take place
in actual iSCSI implementations, such as authentication, encryption, negotiation of various parameters, and different
SCSI operations. The intent here is to provide a baseline understanding of the iSCSI phases and process flow.
The login process is discussed in terms of login phase beginning with the login initial request, followed by optionally
a login partial response to wh ich the initiator replies with mor e login request. The login partial response and more
login request may be repeated a s needed for additional parameter negotiations. A login final r esponse must follow
this phase from the target, indicating either “login accept” or “login reject.”
00
4
8
16
20
24
28
32
48
1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Opcode Opcode-Specific Fields
Total AHS Length Data Segment Length
Logical Unit Number (LUN)
Initiator Task Tag
Expected Data Transfer Length
CmdSN
ExpStatSN
SCSI Command Descriptor Block (CDB)
AHS (if any), Header Digest (if any)
Data Segment – Command Data + Data Digest
(if any)
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 10/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 10 of 15
Login Initiat ion
The iSCSI login is used to establish an iSCSI session between an iSCSI initiator and an iSCSI target. The TCPconnection has to be marked as belonging to an iSCSI session, and pa rameters such as security authentication and
other operation par ameters are exchanged and agreed upon by the iSCSI initiator and the iSCSI target.
This process starts when the initiator opens a TCP connection to the tar get on the target TCP listening port and
assigns a CID. The initiator then sends a login request that includes the protocol version supported by the initiator,
a SSID, the CID, and the negotiation phase the initiator is ready to enter into. O ptionally, the initial request may
contain security parameters or iSCSI operational parameters. Figure 9 illustrates the iSCSI login process.
Figure 9
iSCSI Login Packet Flow
As mentioned earlier, the SSID consists of an ISID and the TSID. The ISID is the first six bytes of the SSID, and it
consists of a 1-byte type, a 3-byte naming authority, and a 2-byte qualifier field (refer to Table 1). The type byte
signifies the format of the naming authority (refer to Table 2). The Naming Authority field of the ISID is the vendor
or organization of this iSCSI initiator component. Lastly, the qualifier isa 16-bit unsigned integer that must be unique
for this particular initiator and target portal group combination.
The TSID isa 16-bit value determined by the target iSCSI node. When the initiator is establishing a new session with
a target , the TSID is set to 0 for the init ial login request . This signals the target that a new session is requested. The
target generates a TSID and returns it in the login response. If an initiator is attempting to establish an add itional
TCP connection for an existing session, the initiator uses the same TSID learned from the previous successful login
attempt w hen the session was created. A nonzero value then signals that t arget that the initiator wishes to add a
connection to an established session. When the initiator receives the TSID from the initial login response, the SSID
is complete and is used to identify this session for all subsequent login PDUs
Establish Normal TCP Session
Single TCP Session
0X03 Command Login
Initial iSCSI Login with Optional
Authentication Negotiation and
Operational Negotiation
0X23 Login Response
iSCSI TargetName is Presented
Authentication Negotiation and Operational Negotiation
0X03 Command Login
Additional Multiple Logins
0X23 Login Response
Login Success, Enter Full Feature Phase
0X04 Optional Text Command
0X24 Text Response
Block Device
Has Already
Initialized Ontothe Fibre
Channel Fabric
TCP Port 3260TCP
iSCSI Driver
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 11/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 11 of 15
.
Authentication and Parameter N egotiation
If the initiator and tar get require authentication, it is negotiated prior to exchanging operational parameters.
Authentication, which may use any of a variety of methods, is discussed further later in this document. Parameter
negotiations may begin with the initial login request sent by the initiator. When authentication (if required) issuccessfully completed, the initiator can proceed with par ameter negotiations. Some operational parameters are
passed using a text format. This exchange uses the following format:
The <value> argument may be numerical, literal, Boolean (yes or no), or a list of comma-separated literal values. If
the originator offers a list of <values>, the responder should reply with the first supported value or “Reject” if it not
supported. A response of “N one” in the case of a literal list is acceptable only if “None” is provided as one of the
possible values. It isalso possible for vendors to add new <key>s by prefixing them with X- followed by their domainname reversed.
Connection
The login process is concluded when the initiator receives a login final response from the target. If the response is
“login reject,” then the attempt failed and the initiator should close the TCP connection identified by the CID. With
a response of “login accept,” the session then enters the full-feature phase (assuming this is the initial login attempt).
Only when full-feature phase is reached can the initiator begin to send SCSI command and data information
conta ined in iSCSI PDUs.
Table 1 Session ID Fields
SSID Byte 0 Byte 1 Byte 2 Byte 3
Word 0 Type Naming authority
Word 1 Qualifier TSID
Initiator portion: ISID
Target portion: TSID
Table 2 Type Byte Definiti ons
Type Naming authority
0x00 IEEE OUI
0x01 IANA enterprise number
0x02 “ Random”
0x03-0xFF Reserved
Originator sends: <key>=<value>
Responder replies: <key>=<value>|None|Reject|NotUnderstood|Irrelevent|
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 12/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 12 of 15
In the case where multiple TCP connections are established (multiple logins) for a given iSCSI session, subsequent
data a nd response PDUs must be sent on the same TCP connection (CID) on which their associated command was
sent. This concept is referred to as “connection allegiance.” In the case where the originating CID has failed,
connection allegiance may be reestablished by the error recovery procedure outlined earlier. Conversely, multiple
commandsassociated with a SCSI task may be sent over different TCP connections. Also, unrelated SCSI commands,
data, and status may be interleaved over the iSCSI session. Each of their respectivedata and responses, however, must
follow the connection allegiance rules.
One of the negotiated operational pa rameters is whether the target operates in solicited (R2T) mode or in the
unsolicited mode for outgoing data transfers (SCSI Write). In unsolicited mode, the initiator may send “immediate
data” in the same PDUas the command (phase collapse), or it can be sent in a separate PDU. The maximum amount
of data the initiator can send for each of these cases may be negotiated at login. When the initial immediate data has
been sent, all subsequent data PDUs must be sent in reply to an R2T response (solicited mode).
The initiator and target utilize the sequence numbering schema outlined earlier to maintain ordering of command,
data, and response exchanges. The initiator may send a SNACK request if it determines an out-of-sync condition.
Based on the sequence number registers, a single SNACK covers a missing contiguous set of data.
Logout and Shutdow n
The logout process providesfor a gracefulshutdown mechanism to closean iSCSI connection or session. The initiator
is responsible for commencing the logout procedure; however, the target may prompt this by sending an
asynchronous iSCSI message indicating an internal error condition. In either case the initiator sends a logout request,
after which no further request may be sent. The logout response from the target indicates that cleanup is complete
and no further responses will be sent on this connection. Additionally, the logout response contains recovery
information from the target. This includes the length of time the target will hold, pending command information for
recovery purposes (Time2Retain) and the length of time the initiator should wait beforeattempting to reestablish the
connection (Time2Wait). Finally, connections are shut down by sending TCP FINs.
Securi ty Considerations
In the past, security as it pertains to storagedevices and storage networks has not been a major consideration. Either
storage devices were directly attached to hosts or they were connected via a separate SAN independent of
user-accessible networks.
With iSCSI, as well as other IP-based SAN protocols, storage information is transported over open IP networks and,
therefore, is subject to security risks. Knowing this, the IP Storage working group has also developed a draft for
securing IP-based storage communications. This work iscontained in the “Securing Block Storage Protocols over IP”
draft. The iSCSI protocol draft specifies two elements relative to security, authentication, and packet protection.
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 13/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 13 of 15
Authentication
With iSCSI, the target may authenticate the initiator and optionally, the initiator may authenticate the target duringthe login process. This would take place prior to any para meter negotiation or login accept. If authentication is
utilized, each connection within the iSCSI session has to be authenticated. The following authentication methods are
defined by the iSCSI draft and are negotiated during the login phase via the “AuthMethod” key:
Although these mechanisms may prevent unauthorized connections to a target device, they provide no protection for
subsequent PDU exchanges.
Packet Protection
Packet protection ensures the integrity, authentication, and confidentiality of communications between iSCSI nodes.
For iSCSI connections, IP Security (IPSec) is utilized to provide secure private exchanges at the IP layer. In order to
be draft compliant, an iSCSI network element must implement IPSec tunnel mode with the Encapsulating Security
Protocol (ESP), including ant i-replay. Because of t he high speeds associated with iSCSI implementations, IPSec
sequence number extensions may/should be implemented, depending on speed.
Confidentiality is obtained by encrypting the IPSec tunnel using Triple Digital Encryption Standard (3DES) in cipher
block chaining (CBC) mode. An iSCSI node must support Internet Key Exchange (IKE) to provide authentication,
security association negotiation, and key management. A separate IKE Phase 2 security association protects each TCP
connection within an iSCSI session.
Implementat ion of iSCSI
The Cisco SN 5420 and 5428 storage routers support iSCSI draft 8. They use iSCSI as the transport for block-level
storage access. Storage devices/ LUNs in the traditional Fibre Channel SAN are presented to the IP network hosts as
if they are directly attached. An iSCSI driver or iSCSI network interface card should be installed in the IP hosts in
order t o suppor t iSCSI operations.
Cisco SN 5420 storageroutersfunction as iSCSI targetswhereas IP hosts function as iSCSI initiators. IP hosts contact
a Cisco SN 5420 Storage Router to perform iSCSI login via a defined iSCSI target add ress and por t. The storage
router either accepts or rejects the login (or multiple logins) based on the information exchanged and parameters
negotiated. The Cisco SN 5420 maps iSCSI targets/LUNs to the actual physical targets/LUNs. If an iSCSI login is
successful, the operation enters full feature phase and data transport is allowed, hencephysical storage targets/LUNs
are available to the iSCSI initiator located in the IP network. Figure 10 illustrates the iSCSI target mode (or SCSI
router mode) of Cisco SN 5420 implementation.
• KRB5 Kerberos V5
• SPKM1 Simplepublic-key generic security service (GSS) application programming interface (API) mechanism
• SPKM2 Simple public-key GSS API mechanism
• SRP Secure Remote Password
• CHAP Challenge Handshake Authentication Protocol
• None No authentication
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 14/15
Cisco Systems, Inc.
All c ontents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reser ved. Important Notices and Privacy Statement.
Page 14 of 15
Figure 10
iSCSI Implementation Example
Besides iSCSI target mode, the Cisco SN 5420 also supports transparent mode and iSCSI multi-initiator mode.
Storage consolidation/centralization in a departmental environment and remote backup are main applications for the
Cisco SN 5420.
For mor e information about t he Cisco SN 5420 Storage Router, consult the Cisco Web page:
http://www.cisco.com/warp/public/cc/pd/rt/5420/.
Summary
The standardization of iSCSI may very well become a disruptive technology in the storage industry. By removing the
physical constraints of traditional storage networks, iSCSI as a minimum is a technology that will significantly impact
workgroup and enterprise networksin the near future. Asstandards-based devices become readilyavailable, network
engineers will need to understand iSCSI as a protocol and the implementation requirements associated with it. This
document focuses specifically on the iSCSI protocol—not implementation considerations. Some of the
implementation topics addressed include performance, security, and application requirements. These considerations
include device capabilities, network capacities, QoS parameters, and application-specific requirements. Additional
resources such as w hite papers, design guides, product certifications, and application notes are available to a ddress
these areas.
Additional resources may be found at:
http://www.cisco.com
http://www.ietf.org/html.charters/ips-charter.html
http://www.snia.org/
References
IETF IPS Working Group, document: draft-ietf-ips-iscsi-14
IETF IPS Working Group, document: draft-ietf-ips-security-11
SCSI-3 Architecture M ode, document number: X3.270-1996
SANIP
Network
SCSI Routing Mode
IP
8/8/2019 Iscsi Intro
http://slidepdf.com/reader/full/iscsi-intro 15/15
Corporate H eadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USA
www.cisco.comTel: 408 526-4000800 553-N ETS (6387)
Fax: 408 526-4100
European HeadquartersCisco Systems Internat ional BVHaarlerbergpark Haarlerbergweg 13-191101 CH Amsterdam
The Netherlandswww-europe.cisco.comTel: 31 0 20 357 1000Fax: 31 0 20 357 1100
Americas Headquart ersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USA
www.cisco.comTel: 408 526-7660Fax: 408 527-0883
Asia Pacific Headquart ersCisco Systems, Inc.Capital Tower168 Robinson Road#22-01 to #29-01
Singapore 068 912www.cisco.comTel: +65 317 7777Fax: +65 317 7799
Cisco Systems has mor e than 2 00 offices in the following countries and r egions. Addresses, phone numbers, and fax numbers ar e listed on the
C i s c o W e b s i t e a t w w w . c i s c o . c o m / g o / o f f i c e s
Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia
Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • H ong Kong SAR • H ungary • India • Indonesia • Ireland
Israel • Italy • Japan • Korea • Luxembourg • M alaysia • M exico • The N etherlands • N ew Z ealand • N orway • Peru • Philippines • Poland
Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden
Sw i t zer la n d • Ta iw a n • T h a i la n d • Tu r k ey • Uk r a in e • Un i t ed Kin gd o m • Un i t ed St a t es • Ven ezu ela • Viet n a m • Z im b a b w e
All contents areCopyright © 1992–2002, CiscoSystems, Inc. All rights reserved.Cisco, Cisco Systems, Cisco IOS,and the Cisco Systemslogo are registered trademarksor trademarkso f Cisco Systems, Inc.and/or its affiliate
in the U.S. and certain other countries.
All o ther t r adem arks m ent ioned in th is docum ent or W eb s ite a r e the pr oper tyof thei r r es pect ive owner s. Theus e of the word partner does not imply a pa rtner sh ip r elat ionsh ip be tween Cisco and any other company
top related