Iscsi Intro

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.

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.



Cisco Systems, Inc.


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.



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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.



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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)



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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|



Cisco Systems, Inc.


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.



Cisco Systems, Inc.


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



Cisco Systems, Inc.


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



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

Iscsi Intro

Documents

Transcript of Iscsi Intro