Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations
draft-ietf-ips-iscsi-reqmts-05
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3347.
|
|
|---|---|---|---|
| Authors | Marjorie Krueger , Randy Haagens | ||
| Last updated | 2015-10-14 (Latest revision 2001-07-05) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 3347 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Allison J. Mankin | ||
| IESG note | ** No value found for 'doc.notedoc.note' ** | ||
| Send notices to | <ElizabethRodriguez@ieee.org> |
draft-ietf-ips-iscsi-reqmts-05
IP Storage Working Group M. Krueger
R. Haagens
Internet Draft Hewlett-Packard
Corporation
Category: Informational
C. Sapuntzakis
M. Bakke
Cisco Systems
Document: draft-ietf-ips-iscsi-reqmts-05.txt July 2001
iSCSI Requirements and Design Considerations
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The IP Storage Working group is chartered with developing
comprehensive technology to transport block storage data over IP
protocols. This effort includes a protocol to transport the Small
Computer Systems Interface (SCSI) protocol over the Internet
(iSCSI). The initial version of the iSCSI protocol will define a
mapping of SCSI transport protocol over TCP/IP so that SCSI storage
controllers (principally disk and tape arrays and libraries) can be
attached to IP networks, notably Gigabit Ethernet (GbE) and 10
Gigabit Ethernet (10 GbE).
This document specifies the requirements iSCSI and it's related
infrastructure should satisfy and the design considerations guiding
the iSCSI protocol development efforts. In the interest of timely
adoption of the iSCSI protocol, the IPS group has chosen to focus
Krueger Informational Expires August 2001 1
iSCSI Reqmnts and Design Considerations Nov. 2000
the first version of the protocol to work with the existing SCSI
architecture and commands, and the existing TCP/IP transport layer.
Both these protocols are widely-deployed and well-understood. The
thought is that using these mature protocols will entail a minimum
of new invention, the most rapid possible adoption, and the greatest
compatibility with Internet architecture, protocols, and equipment.
The iSCSI protocol is a mapping of SCSI to TCP, and constitutes a
"SCSI transport" as defined by the ANSI T10 document SCSI SAM-2
document [SAM2, p. 3, "Transport Protocols"].
Conventions used in this document
This document describes the requirements for a protocol design,
but does not define a protocol standard. Nevertheless, the
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Table of Contents
1. Summary of Requirements...........................................3
2. iSCSI Design Considerations.......................................7
2.1. General Discussion..............................................7
2.2. Performance/Cost................................................8
2.3. Framing.........................................................10
2.4. High bandwidth, bandwidth aggregation...........................11
3. Ease of implementation/complexity of protocol.....................13
4. Reliability and Availability......................................13
4.1. Detection of Data Corruption....................................14
4.2. Recovery........................................................14
5. Interoperability..................................................15
5.1. Internet infrastructure.........................................15
5.2. SCSI............................................................15
6. Security Considerations...........................................16
6.1. Extensible Security.............................................17
6.2. Authentication..................................................17
6.3. Data Integrity..................................................18
6.4. Data Confidentiality............................................18
7. Management........................................................18
7.1. Naming..........................................................18
7.2. Discovery.......................................................19
8. Internet Accessibility............................................20
8.1. Denial of Service...............................................20
8.2. Firewalls and Proxy servers.....................................20
8.3. Congestion Control and Transport Selection......................21
9. Definitions.......................................................21
10. References........................................................21
11. Acknowledgements..................................................22
12. Author's Addresses................................................22
Krueger Informational Exp. May 2001 2
iSCSI Reqmnts and Design Considerations Nov. 2000
1. Summary of Requirements
The iSCSI standard:
>From section 2.2 Performance/Cost:
MUST allow implementations to equal or improve on the current state
of the art for SCSI interconnects.
MUST enable cost competitive implementations.
SHOULD minimize control overhead to enable low delay communications.
MUST provide high bandwidth and bandwidth aggregation.
MUST have low host CPU utilizations, equal to or better than current
technology.
MUST be possible to build I/O adapters that handle the entire SCSI
task.
SHOULD permit direct data placement architectures.
MUST NOT impose complex operations on host software.
MUST provide for full utilization of available link bandwidth.
MUST allow an implementation to exploit parallelism (multiple
connections) at the device interfaces and within the interconnect
fabric.
>From section 2.4 High Bandwidth/Bandwidth Aggregation:
MUST operate over a single TCP connection.
SHOULD support 'connection binding', and it MUST be optional to
implement.
>From section 3 Ease of Implementation/Complexity of Protocol:
SHOULD keep the protocol simple.
SHOULD minimize optional features.
MUST specify feature negotiation at session establishment (login).
MUST operate correctly when no optional features are negotiated as
well as when individual option negotions are unsuccessful.
>From section 4.1 Detection of Data Corruption:
MUST support a data integrity check format for use in digest
generation.
Krueger Informational Exp. May 2001 3
iSCSI Reqmnts and Design Considerations Nov. 2000
MAY use separate digest for data and headers.
iSCSI header format SHOULD be extensible to include other data
integrity digest calculation methods.
>From section 4.2 Recovery:
MUST specify mechanisms to recover in a timely fashion from
failures on the initiator, target, or connecting infrastructure.
MUST specify recovery methods for non-idempotent requests.
SHOULD take into account fail-over schemes for mirrored targets or
highly available storage configurations.
SHOULD provide a method for sessions to be gracefully terminated and
restarted that can be initiated by either the initiator or target.
>From section 5 Interoperability:
iSCSI protocol document MUST be clear and unambiguous.
>From section 5.1 Internet Infrastructure:
MUST:
-- be compatible with both IPv4 and IPv6
-- use TCP connections conservatively, keeping in mind there may be
many other users of TCP on a given machine.
MUST NOT require changes to existing Internet protocols.
SHOULD minimize required changes to existing TCP/IP
implementations.
>From section 5.2 SCSI:
Any feature SAM2 requires in a valid transport mapping MUST be
specified by iSCSI.
MUST specify strictly ordered delivery of SCSI commands over an
iSCSI session between an initiator/target pair.
The command ordering mechanism SHOULD seek to minimize the amount of
communication necessary across multiple adapters doing transport
off-load.
MUST specify for each feature whether it is OPTIONAL, RECOMMENDED or
REQUIRED to implement and/or use.
MUST NOT require changes to the SCSI-3 command sets and SCSI client
code except except where SCSI specifications point to "transport
dependant" fields and behavior.
SHOULD track changes to SCSI and the SCSI Architecture Model.
Krueger Informational Exp. May 2001 4
iSCSI Reqmnts and Design Considerations Nov. 2000
MUST be capable of supporting all SCSI-3 command sets and device
types.
SHOULD support ACA implementation.
MUST allow for the construction of gateways to other SCSI transports
MUST reliably transport SCSI commands from the initiator to the
target.
MUST correctly deal with iSCSI packet drop, duplication, corruption,
stale packets, and re-ordering.
>From section 6.1 Extensible Security:
SHOULD require minimal configuration and overhead in the insecure
operation.
SHOULD provide for strong authentication when increased security is
required.
SHOULD allow integration of new security mechanisms without breaking
backwards compatible operation.
>From section 6.2 Authentication:
MAY support various levels of authentication security.
MUST support private authenticated login.
iSCSI authenticated login MUST be resilient against passive attacks.
MUST support data origin authentication of its communications; data
origin authentication MAY be optional to use.
>From section 6.3 Data Integrity:
SHOULD NOT preclude use of additional data integrity protection
protocols (IPSec, TLS).
>From section 6.4 Data Confidentiality:
MAY use a data encryption protocol such as TLS or IPsec ESP to
provide data confidentiality between iSCSI endpoints.
>From section 7 Management:
SHOULD be manageable using standard IP-based management protocols
(eg. SNMP, RMI, etc).
iSCSI protocol document MUST NOT define the management architecture
for iSCSI, or make explicit references to management objects such as
MIB variables.
>From section 7.1 Naming:
MUST support the naming architecture of SAM-2.
Krueger Informational Exp. May 2001 5
iSCSI Reqmnts and Design Considerations Nov. 2000
The means by which an iSCSI resource is located MUST use or extend
existing Internet standard resource location methods.
MUST provide a means of identifying iSCSI targets by a unique
identifier that is independent of the path on which it is found.
The format for the iSCSI names MUST use existing naming authorities.
An iSCSI name SHOULD be a human readable string in an international
character set encoding.
Standard Internet lookup services SHOULD be used to resolve iSCSI
names.
SHOULD deal with the complications of the new SCSI security
architecture.
iSCSI naming architecture MUST address support of SCSI 3rd party
operations such as EXTENDED COPY.
>From section 7.2 Discovery:
MUST have no impact on the use of current IP network discovery
techniques.
MUST provide some means of determining whether an iSCSI service is
available through an IP address.
SCSI protocol-dependent techniques SHOULD be used for further
discovery beyond the iSCSI layer.
MUST provide a method of discovering, given an IP end point on its
well-known port, the list of SCSI targets available to the
requestor. The use of this discovery service MUST be optional.
>From section 8 Internet Accessability.
SHOULD be scrutinized for denial of service issues and they should
be addressed.
>From section 8.2 Firewalls and Proxy Servers
SHOULD allow deployment where functional and optimizing middle-boxes
such as firewalls, proxy servers and NATs are present.
use of IP addresses and TCP ports SHOULD be firewall friendly.
>From section 8.3 Congestion Control and Transport Selection
MUST be a good network citizen with TCP-compatible congestion
control (as defined in RFC 2309).
Krueger Informational Exp. May 2001 6
iSCSI Reqmnts and Design Considerations Nov. 2000
iSCSI implementations MUST NOT use multiple connections as a means
to avoid transport-layer congestion control.
2. iSCSI Design Considerations
2.1. General Discussion
Traditionally, storage controllers (e.g., disk array controllers,
tape library controllers) have supported the SCSI-3 protocol and
have been attached to computers by SCSI parallel bus or Fibre
Channel.
The IP infrastructure offers compelling advantages for volume/block-
oriented storage attachment. It offers the opportunity to take
advantage of the performance/cost benefits provided by competition
in the Internet marketplace. This could reduce the cost of storage
network infrastructure by providing economies arising from the need
to install and operate only a single type of network.
In addition, the IP protocol suite offers the opportunity for a rich
array of management, security and QoS solutions. Organizations may
initially choose to operate storage networks based on iSCSI that are
independent of (isolated from) their current data networks except
for secure routing of storage management traffic. These
organizations anticipate benefits from the high performance/cost of
IP equipment and a the opportunity for a unified management
architecture. As security and QoS evolve, it becomes reasonable to
build combined networks with shared infrastructure; nevertheless, it
is likely that sophisticated users will choose to keep their storage
sub-networks isolated to afford the best control of security and QoS
to ensure a high-performance environment tuned to storage traffic.
Mapping SCSI over IP also provides:
-- Extended distance ranges
-- Connectivity to "carrier class" services that support IP
The following applications for iSCSI are contemplated:
-- Local storage access, consolidation, clustering and pooling (as
in the data center)
-- Network client access to remote storage (eg. a "storage service
provider")
-- Local and remote synchronous and asynchronous mirroring between
storage controllers
-- Local and remote backup and recovery
iSCSI will support the following topologies:
-- Point-to-point direct connections
Krueger Informational Exp. May 2001 7
iSCSI Reqmnts and Design Considerations Nov. 2000
-- Dedicated storage LAN, consisting of one or more LAN segments
-- Shared LAN, carrying a mix of traditional LAN traffic plus
storage traffic
-- LAN-to-WAN extension using IP routers or carrier-provided "IP
Datatone"
-- Private networks and the public Internet
IP LAN-WAN routers may be used to extend the IP storage network to
the wide area, permitting remote disk access (as for a storage
utility), synchronous and asynchronous remote mirroring, and remote
backup and restore (as for tape vaulting). In the WAN, using TCP
end-to-end avoids the need for specialized equipment for protocol
conversion, ensures data reliability, copes with network congestion,
and provides retransmission strategies adapted to WAN delays.
The iSCSI technology deployment will involve the following elements:
(1) Conclusion of a complete protocol standard and supporting
implementations;
(2) Development of Ethernet storage NICs and related driver and
protocol software; [NOTE: high-speed applications of iSCSI are
expected to require significant portions of the iSCSI/TCP/IP
implementation in hardware to achieve the necessary
throughput.]
(3) Development of compatible storage controllers; and
(4) The likely development of translating gateways to provide
connectivity between the Ethernet storage network and the
Fibre Channel and/or parallel-bus SCSI domains.
(5) Development of specifications for iSCSI device management such
as MIBs, LDAP or XML schemas, etc.
(6) Development of management and directory service applications
to support a robust SAN infrastructure.
Products could initially be offered for Gigabit Ethernet attachment,
with rapid migration to 10 GbE. For performance competitive with
alternative SCSI transports, it will be necessary to implement the
performance path of the full protocol stack in hardware. These new
storage NICs might perform full-stack processing of a complete SCSI
task, analogous to today's SCSI and Fibre Channel HBAs, and might
also support all host protocols that use TCP (NFS, CIFS, HTTP, etc).
The charter of the IETF IP Storage Working Group (IPSWG) describes
the broad goal of mapping SCSI to IP using a transport that has
proven congestion avoidance behavior and broad implementation on a
variety of platforms. Within that broad charter, several transport
alternatives may be considered. Initial IPS work focuses on TCP,
and this requirements document is restricted to that domain of
interest.
2.2. Performance/Cost
Krueger Informational Exp. May 2001 8
iSCSI Reqmnts and Design Considerations Nov. 2000
In general, iSCSI MUST allow implementations to equal or improve on
the current state of the art for SCSI interconnects. This goal
breaks down into several types of requirement:
Cost competitive with alternative storage network technologies:
In order to be adopted by vendors and the user community, the iSCSI
protocol MUST enable cost competitive implementations when compared
to other SCSI transports (Fibre Channel).
Low delay communication:
Conventional storage access is of a stop-and-wait or remote
procedure call type. Applications typically employ very little
pipelining of their storage accesses, and so storage access delay
directly impacts performance. The delay imposed by current storage
interconnects, including protocol processing, is generally in the
range of 100 microseconds. The use of caching in storage
controllers means that many storage accesses complete almost
instantly, and so the delay of the interconnect can have a high
relative impact on overall performance. When stop-and-wait IO is
used, the delay of the interconnect will affect performance. The
iSCSI protocol SHOULD minimize control overhead, which adds to
delay.
Low host CPU utilization, equal to or better than current
technology:
For competitive performance, the iSCSI protocol MUST allow three key
implementation goals to be realized:
(1) iSCSI MUST make it possible to build I/O adapters that handle
an entire SCSI task, as alternative SCSI transport
implementations do.
(2) The protocol SHOULD permit direct data placement ("zero-copy"
memory architectures, where the I/O adapter reads or writes
host memory exactly once per disk transaction.
(3) The protocol SHOULD NOT impose complex operations on the host
software, which would increase host instruction path length
relative to alternatives.
Direct data placement (zero-copy iSCSI):
Direct data placement refers to iSCSI data being placed directly
"off the wire" into the allocated location in memory with no
intermediate copies. Direct data placement significantly reduces
the memory bus and I/O bus loading in the endpoint systems, allowing
improved performance. It reduces the memory required for NICs,
possibly reducing the cost of these solutions.
This is an important implementation goal. In an iSCSI system, each
of the end nodes (for example host computer and storage controller)
Krueger Informational Exp. May 2001 9
iSCSI Reqmnts and Design Considerations Nov. 2000
should have ample memory, but the intervening nodes (NIC, switches)
typically will not.
High bandwidth, bandwidth aggregation:
The bandwidth (transfer rate, MB/sec) supported by storage
controllers is rapidly increasing, due to several factors:
1. Increase in disk spindle and controller performance;
2. Use of ever-larger caches, and improved caching algorithms;
3. Increased scale of storage controllers (number of supported
spindles, speed of interconnects).
The iSCSI protocol MUST provide for full utilization of available
link bandwidth. The protocol MUST also allow an implementation to
exploit parallelism (multiple connections) at the device interfaces
and within the interconnect fabric.
The next two sections further discuss the need for direct data
placement and high bandwidth.
2.3. Framing
Framing refers to the addition of information in a header, or the
data stream to allow implementations to locate the boundaries of an
iSCSI protocol data unit (PDU) within the TCP byte stream. There
are two technical requirements driving framing: interfacing needs,
and accelerated processing needs.
A framing solution that addresses the "interfacing needs" of the
iSCSI protocol will facilitate the implementation of a message-based
upper layer protocol (iSCSI) on top of an underlying byte streaming
protocol (TCP). Since TCP is a reliable transport, this can be
accomplished by including a length field in the iSCSI header.
Finding the protocol frame assumes that the receiver will parse from
the beginning of the TCP data stream, and never make a mistake (lose
alignment on packet headers).
The other technical requirement for framing, "accelerated
processing", stems from the need to handle increasingly higher data
rates in the physical media interface. Two needs arise from higher
data rates:
(1) LAN environment - NIC vendors seek ways to provide "zero-copy"
methods of moving data directly from the wire into application
buffers.
(2) WAN environment- the emergence of high bandwidth, high latency,
low bit error rate physical media places huge buffer
requirements on the physical interface solutions.
Krueger Informational Exp. May 2001 10
iSCSI Reqmnts and Design Considerations Nov. 2000
First, vendors are producing network processing hardware that
offloads network protocols to hardware solutions to achieve higher
data rates. The concept of "zero-copy" seeks to store blocks of
data in appropriate memory locations (aligned) directly off the
wire, even when data is reordered due to packet loss. This is
necessary to drive actual data rates of 10 Gigabit/sec and beyond.
Secondly, in order for iSCSI to be successful in the WAN arena it
must be possible to operate efficiently in high bandwidth, high
delay networks. The emergence of multi-gigabit IP networks with
latencies in the tens to hundreds of milliseconds presents a
challenge. To fill such large pipes, it is necessary to have tens of
megabytes of outstanding requests from the application. In addition,
some protocols potentially require tens of megabytes at the
transport layer to deal with buffering for reassembly of data when
packets are received out-of-order.
In both cases, the issue is the desire to minimize the amount of
memory and memory bandwidth required for iSCSI hardware solutions.
Consider that a network pipe at 10 Gbps x 200 msec holds 250 MB.
[Assume land-based communication with a spot half way around the
world at the equator. Ignore additional distance due to cable
routing. Ignore repeater and switching delays; consider only a
speed-of-light delay of 5 microsec/km. The circumference of the
globe at the equator is approx. 40000 km (round-trip delay must be
considered to keep the pipe full). 10 Gb/sec x 40000 km x 5
microsec/km x B / 8b = 250 MB]. In a conventional TCP
implementation, loss of a TCP segment means that stream processing
MUST stop until that segment is recovered, which takes at least a
time of <network round trip> to accomplish. Following the example
above, an implementation would be obliged to catch 250 MB of data
into an anonymous buffer before resuming stream processing; later,
this data would need to be moved to its proper location. Some
proponents of iSCSI seek some means of putting data directly where
it belongs, and avoiding extra data movement in the case of segment
drop. This is a key concept in understanding the debate behind
framing methodologies.
The framing of the iSCSI protocol impacts both the "interfacing
needs" and the "accelerated processing needs", however, while
including a length in a header may suffice for the "interfacing
needs", it will not serve the direct data placement needs. The
framing mechanism developed should allow resynchronization of packet
boundaries even in the case where a packet is temporarily missing in
the incoming data stream.
2.4. High bandwidth, bandwidth aggregation
At today's block storage transport throughput, any single link can
be saturated by the volume of storage traffic. Scientific data
Krueger Informational Exp. May 2001 11
iSCSI Reqmnts and Design Considerations Nov. 2000
applications and data replication are examples of storage
applications that push the limits of throughput.
Some applications, such as log updates, streaming tape, and
replication, require ordering of updates and thus ordering of SCSI
commands. An initiator may maintain ordering by waiting for each
update to complete before issuing the next (a.k.a. synchronous
updates). However, the throughput of synchronous updates decreases
inversely with increases in network distances.
For greater throughput, the SCSI task queuing mechanism allows an
initiator to have multiple commands outstanding at the target
simultaneously and to express ordering constraints on the execution
of those commands. The task queuing mechanism is only effective if
the commands arrive at the target in the order they were presented
to the initiator (FIFO order). The iSCSI standard must provide an
ordered transport of SCSI commands, even when commands are sent
along different network paths (see Section 5.2 SCSI). This is
referred to as "command ordering".
The iSCSI protocol MUST operate over a single TCP connection to
accomodate lower cost implementations. To enable higher performance
storage devices, the protocol should specify a means to allow
operation over multiple connections while maintaining the behavior
of a single SCSI port. This would allow the initiator and target
to use multiple network interfaces and multiple paths through the
network for increased throughput. There are a few potential ways to
satisfy the multiple path and ordering requirements.
A popular way to satisfy the multiple-path requirement is to have a
driver above the SCSI layer instantiate multiple copies of the SCSI
transport, each communicating to the target along a different path.
"Wedge" drivers use this technique today to attain high performance.
Unfortunately, wedge drivers must wait for acknowledgement of
completion of each request (stop-and-wait) to ensure ordered
updates.
Another approach might be for iSCSI protocol to use multiple
instances of its underlying transport (e.g. TCP). The iSCSI layer
would make these independent transport instances appear as one SCSI
transport instance and maintain the ability to do ordered SCSI
command queuing. The document will refer to this technique as
"connection binding" for convenience.
The iSCSI protocol SHOULD support connection binding, and it MUST be
optional to implement.
In the presence of connection binding, there are two ways to assign
features to connections. In the symmetric approach, all the
connections are identical from a feature standpoint. In the
asymmetric model, connections have different features. For example,
some connections may be used primarily for data transfers whereas
others are used primarily for SCSI commands.
Krueger Informational Exp. May 2001 12
iSCSI Reqmnts and Design Considerations Nov. 2000
Since the iSCSI protocol must support the case where there was only
one transport connection, the protocol must have command, data, and
status travel over the same connection.
In the case of multiple connections, the iSCSI protocol must keep
the command and its associated data and status on the same
connection (connection allegiance). Sending data and status on the
same connection is desirable because this guarantees that status is
received after the data (TCP provides ordered delivery). In the case
where each connection is managed by a separate processor, allegiance
decreases the need for inter-processor communication. This
symmetric approach is a natural extension of the single connection
approach.
An alternate approach that was extensively discussed involved
sending all commands on a single connection and the associated data
and status on a different connection (asymetric approach). In this
scheme, the transport ensures the commands arrive in order. The
protocol on the data and status connections is simpler, perhaps
lending itself to a simpler realization in hardware. One
disadvantage of this approach is that the recovery procedure is
different if a command connection fails vs. a data connection. Some
argued that this approach would require greater inter-processor
communication when connections are spread across processors.
The reader may reference the mail archives of the IPS mailing list
between June and September of 2000 for extensive discussions on
symmetric vs asymmetric connection models.
3. Ease of implementation/complexity of protocol
Experience has shown that adoption of a protocol by the Internet
community is inversely proportional to its complexity. In addition,
the simpler the protocol, the easier it is to diagnose problems.
The designers of iSCSI SHOULD strive to fulfill the requirements of
the creating a SCSI transport over IP, while keeping the protocol as
simple as possible.
In the interest of simplicity, iSCSI SHOULD minimize optional
features. When features are deemed necessary, the protocol MUST
specify feature negotiation at session establishment (login). The
iSCSI transport MUST operate correctly when no optional features are
negotiated as well as when individual option negotions are
unsuccessful.
4. Reliability and Availability
Krueger Informational Exp. May 2001 13
iSCSI Reqmnts and Design Considerations Nov. 2000
4.1. Detection of Data Corruption
There have been several research papers that suggest that the TCP
checksum calculation allows a certain number of bit errors to pass
undetected [10] [11].
In order to protect against data corruption, the iSCSI protocol MUST
support a data integrity check format for use in digest generation.
The iSCSI protocol MAY use separate digests for data and headers. In
an iSCSI proxy or gateway situation, the iSCSI headers are removed
and re-built, and the TCP stream is terminated on either side. This
means that even the TCP checksum is removed and recomputed within
the gateway. To ensure the protection of commands, data, and status
the iSCSI protocol MUST include a CRC or other digest mechanism that
is computed on the SCSI data block itself, as well as on each
command and status message. Since gateways may strip iSCSI headers
and rebuild them, a separate header CRC is required. Two header
digests, one for invariant portions of the header (addresses) and
one for the variant portion would provide protection against changes
to portions of the header that should never be changed by middle
boxes (eg, addresses).
The iSCSI header format SHOULD be extensible to include other digest
calculation methods.
4.2. Recovery
The SCSI protocol was originally designed for a parallel bus
transport that was highly reliable. SCSI applications tend to
assume that transport errors never happen, and when they do, SCSI
application recovery tends to be expensive in terms of time and
computational resources.
iSCSI protocol design, while placing an emphasis on simplicity, MUST
lead to timely recovery from failure of initiator, target, or
connecting network infrastructure (cabling, data path equipment such
as routers, etc).
iSCSI MUST specify recovery methods for non-idempotent requests,
such as operations on tape drives.
The iSCSI protocol error recover mechanism SHOULD take into account
fail-over schemes for mirrored targets or highly available storage
configurations that provide paths to target data through multiple
"storage servers". This would provide a basis for layered
technologies like high availability and clustering.
The iSCSI protocol SHOULD also provide a method for sessions to be
gracefully terminated and restarted that can be initiated by either
the initiator or target. This provides the ability to gracefully
Krueger Informational Exp. May 2001 14
iSCSI Reqmnts and Design Considerations Nov. 2000
fail over an initiator or target, or reset a target after performing
maintenance tasks such as upgrading software.
5. Interoperability
It must be possible for initiators and targets that implement the
required portions of the iSCSI specification to interoperate. While
this requirement is so obvious that it doesn't seem worth
mentioning, if the protocol specification contains ambiguous
wording, different implementations may not interoperate. The iSCSI
protocol document MUST be clear and unambiguous.
5.1. Internet infrastructure
The iSCSI protocol MUST:
-- be compatible with both IPv4 and IPv6.
-- use TCP connections conservatively, keeping in mind there may be
many other users of TCP on a given machine.
The iSCSI protocol MUST NOT require changes to existing Internet
protocols and SHOULD minimize required changes to existing TCP/IP
implementations.
5.2. SCSI
In order to be considered a SCSI transport, the iSCSI standard must
comply with the requirements of the SCSI Architecture Model [SAM2]
for a SCSI transport. Any feature SAM2 requires in a valid
transport mapping MUST be specified by iSCSI. The iSCSI protocol
document MUST specify for each feature whether it is OPTIONAL,
RECOMMENDED or REQUIRED to implement and/or use.
The SCSI Architectural Model [SAM-2] indicates an expectation that
the SCSI transport provides ordering of commands on an initiator-
target-LUN granularity. There has been much discussion on the IPS
reflector and in working group meetings regarding the means to
ensure this ordering. The rough consensus is that iSCSI MUST
specify strictly ordered delivery of SCSI commands over an iSCSI
session between an initiator/target pair, even in the presence of
transport errors. This command ordering mechanism SHOULD seek to
minimize the amount of communication necessary across multiple
adapters doing transport off-load. If an iSCSI implementation does
not require ordering it can instantiate multiple sessions per
initiator-target pair.
iSCSI is intended to be a new SCSI "transport" [SAM2]. As a mapping
of SCSI over TCP, iSCSI requires interaction with both T10 and IETF.
However, the iSCSI protocol MUST NOT require changes to the SCSI-3
Krueger Informational Exp. May 2001 15
iSCSI Reqmnts and Design Considerations Nov. 2000
command sets and SCSI client code except where SCSI specifications
point to "transport dependant" fields and behavior. For example,
changes to SCSI documents will be necessary to reflect lengthier
iSCSI target names and potentially lengthier timeouts.
Collaboration with T10 will be necessary to achieve this
requirement.
The iSCSI protocol SHOULD track changes to SCSI and the SCSI
Architecture Model.
The iSCSI protocol MUST be capable of supporting all SCSI-3 command
sets and device types. The primary focus is on supporting 'larger'
devices: host computers and storage controllers (disk arrays, tape
libraries). However, other command sets (printers, scanners) must
be supported. These requirements MUST NOT be construed to mean that
iSCSI must be natively implementable on all of today's SCSI devices,
which might have limited processing power or memory.
ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that
stops execution of a sequence of dependent SCSI commands when one of
them fails. The situation surrounding it is complex - T10 specifies
ACA in SAM2, and hence iSCSI must support it and endeavor to make
sure that ACA gets implemented sufficiently (two independent
interoperable implementations) to avoid dropping ACA in the
transition from Proposed Standard to Draft Standard. This implies
iSCSI SHOULD support ACA implementation.
The iSCSI protocol MUST allow for the construction of gateways to
other SCSI transports, including parallel SCSI [SPI-X] and to SCSI-
FCP[FCP, FCP-2]. It MUST be possible to construct "translating"
gateways so that iSCSI hosts can interoperate with SCSI-X devices;
so that SCSI-X devices can communicate over an iSCSI network; and so
that SCSI-X hosts can use iSCSI targets (where SCSI-X refers to
parallel SCSI, SCSI-FCP, or SCSI over any other transport). This
requirement is implied by support for SAM-2, but is worthy of
emphasis. These are true application protocol gateways, and not just
bridge/routers. The different standards have only the SCSI-3
command set layer in common. These gateways are not mere packet
forwarders.
The iSCSI protocol MUST reliably transport SCSI commands from the
initiator to the target. According to [SAM-2, p. 17.] "The function
of the service delivery subsystem is to transport an error-free copy
of the request or response between the sender and the receiver"
[SAM-2, p. 22]. The iSCSI protocol MUST correctly deal with iSCSI
packet drop, duplication, corruption, stale packets, and re-
ordering.
6. Security Considerations
Krueger Informational Exp. May 2001 16
iSCSI Reqmnts and Design Considerations Nov. 2000
In the past, directly attached storage systems have implemented
minimal security checks because the physical connection offered
little chance for attack. Transporting block storage (SCSI) over
IP opens a whole new opportunity for a variety of malicious attacks.
Attacks can take the active form (identity spoofing, man-in-the-
middle) or the passive form (eavesdropping).
6.1. Extensible Security
The security services required for communications depends on the
individual network configurations and environments. Organizations
are setting up Virtual Private Networks(VPN), also known as
Intranets, that will require one set of security functions for
communications within the VPN and possibly many different security
functions for communications outside the VPN to support
geographically separate components. The iSCSI protocol is
applicable to a wide range of internetworking environments that may
employ different security policies. The protocol SHOULD require
minimal configuration and overhead in the insecure operation,
provide for strong authentication when increased security is
required, and allow integration of new security mechanisms without
breaking backwards compatible operation.
6.2. Authentication
The iSCSI protocol MAY support various levels of authentication
security, ranging from no authentication to secure authentication
using public or private keys.
The iSCSI protocol MUST support private authenticated login.
Authenticated login aids the target in blocking the unauthorized use
of SCSI resources. "Private" authenticated login mandates protected
identity exchange (no clear text passwords at a minimum). Since
block storage confidentiality is considered critical in enterprises
and many IP networks may have access holes, organizations will want
to protect their iSCSI resources.
The iSCSI authenticated login MUST be resilient against passive
attacks since many IP networks are vulnerable to packet inspection.
In addition, the iSCSI protocol MUST support data origin
authentication of its communications; data origin authentication MAY
be optional to use. Data origin authentication is critical since IP
networks are vulnerable to source spoofing, where a malicious third
party pretends to send packets from the initiator's IP address.
These requirements should be met using standard Internet protocols
such as IPsec or TLS. The endpoints may negotiate the authentication
method, optionally none.
Krueger Informational Exp. May 2001 17
iSCSI Reqmnts and Design Considerations Nov. 2000
6.3. Data Integrity
The iSCSI protocol SHOULD NOT preclude use of additional data
integrity protection protocols (IPSec, TLS).
6.4. Data Confidentiality
Block storage is used for storing sensitive information, where data
confidentiality is critical. An application may encrypt the data
blocks before writing them to storage - this provides the best
protection for the application. Even if the storage or
communications are compromised, the attacker will have difficulty
reading the data.
In certain environments, encryption may be desired to provide an
extra assurance of confidentiality. An iSCSI implementation MAY use
a data encryption protocol such as TLS or IPsec ESP to provide data
confidentiality between iSCSI endpoints.
7. Management
iSCSI implementations SHOULD be manageable using standard IP-based
management protocols (eg. SNMP, RMI, etc). However, the iSCSI
protocol document MUST NOT define the management architecture for
iSCSI within the network infrastructure. iSCSI will be yet another
resource service within a complex environment of network resources
(printers, file servers, NAS, application servers, etc). There will
certainly be efforts to design how the "block storage service" that
iSCSI devices provide is integrated into a comprehensive, shared
model, network management environment. A "network administrator"
(or "storage administrator") will desire to have integrated
applications for assigning user names, resource names, etc. and
indicating access rights. iSCSI devices presumably will want to
interact with these integrated network management applications. The
iSCSI protocol document will not attempt to solve that set of
problems, or specify means for devices to provide management agents.
In fact, there should be no mention of MIBs or any other means of
managing iSCSI devices as explicit references in the iSCSI protocol
document, because management data and protocols change with the
needs of the environment and the business models of the management
applications.
7.1. Naming
Whenever possible, iSCSI MUST support the naming architecture of
SAM-2. Deviations and uncertainties MUST be made explicit, and
comments and resolutions worked out between ANSI T10 and the IPS
working group.
Krueger Informational Exp. May 2001 18
iSCSI Reqmnts and Design Considerations Nov. 2000
The means by which an iSCSI resource is located MUST use or extend
existing Internet standard resource location methods. RFC 1783 [12]
specifies URL syntax and semantics which should be sufficiently
extensible for the iSCSI resource.
The iSCSI protocol MUST provide a means of identifying an iSCSI
storage device by a unique identifier that is independent of the
path on which it is found. This name will be used to correlate
alternate paths to the same device. The format for the iSCSI names
MUST use existing naming authorities, to avoid creating new central
administrative tasks. An iSCSI name SHOULD be a human readable
string in an international character set encoding.
Standard Internet lookup services SHOULD be used to resolve names.
For example, Domain Name Services (DNS) MAY be used to resolve the
<hostname> portion of a URL to one or multiple IP addresses. When a
hostname resolves to multiple addresses, these addresses should be
equivalent for functional (possibly not performance) purposes. This
means that the addresses can be used interchangeably as long as
performance isn't a concern. For example, the same set of SCSI
targets MUST be accessible from each of these addresses.
An iSCSI device naming scheme MUST interact correctly with the
proposed SCSI security architecture [99-245r9]. Particular
attention must be directed to the proxy naming architecture defined
by the new security model. In this new model, a host is identified
by an Access ID, and SCSI Logical Unit Numbers (LUNs) can be mapped
in a manner that gives each AccessID a unique LU map. Thus, a given
LU within a target may be addressed by different LUNs.
The iSCSI naming architecture MUST address support of SCSI 3rd party
operations such as EXTENDED COPY. The key issue here relates to the
naming architecture for SCSI LUs - iSCSI must provide a means of
passing a name or handle between parties. iSCSI must specify a means
of providing a name or handle that could be used in the XCOPY
command and fit within the available space allocated by that
command. And it must be possible, of course, for the XCOPY target
(the third party) to dereference the name to the correct target and
LU.
7.2. Discovery
iSCSI MUST have no impact on the use of current IP network discovery
techniques. Network management platforms discover IP addresses and
have various methods of probing the services available through these
IP addresses. An iSCSI service should be evident using similar
techniques.
The iSCSI specifications MUST provide some means of determining
whether an iSCSI service is available through an IP address. It is
Krueger Informational Exp. May 2001 19
iSCSI Reqmnts and Design Considerations Nov. 2000
expected that iSCSI will be a point of service in a host, just as
SNMP, etc are points of services, associated with a well known port
number.
SCSI protocol-dependent techniques SHOULD be used for further
discovery beyond the iSCSI layer. Discovery is a complex, multi-
layered process. The SCSI protocol specifications provide specific
commands for discovering LUs and the commands associated with this
process will also work over iSCSI.
The iSCSI protocol MUST provide a method of discovering, given an IP
end point on its well-known port, the list of SCSI targets available
to the requestor. The use of this discovery service MUST be
optional.
Further discovery guidelines are outside the scope of this document
and may be addressed in separate Informational drafts.
8. Internet Accessibility
8.1. Denial of Service
As with all services, the denial of service by either incorrect
implementations or malicious agents is always a concern. All
aspects of the iSCSI protocol SHOULD be scrutinized for potential
denial of service issues, and guarded against as much as possible.
8.2. NATs, Firewalls and Proxy servers
NATs (Network Address Translator), firewalls, and proxy servers are
a reality in today's Internet. These devices present a number of
challenges to device access methods being developed for iSCSI. For
example, specifying a URL syntax for iSCSI resource connection
allows an initiator to address an iSCSI target device both directly
and through an iSCSI proxy server or NAT. iSCSI SHOULD allow
deployment where functional and optimizing middle-boxes such as
firewalls, proxy servers and NATs are present.
The iSCSI protocols use of IP addressing and TCP port numbers MUST
be firewall friendly. This means that all connection requests should
normally be addressed to a specific, well-known TCP port. That way,
firewalls can filter based on source and destination IP addresses,
and destination (target) port number. Additional TCP connections
would require different source port numbers (for uniqueness), but
could be opened after a security dialogue on the control channel.
It's important that iSCSI operate through a firewall to provide a
possible means of defending against Denial of Service (DoS) assaults
Krueger Informational Exp. May 2001 20
iSCSI Reqmnts and Design Considerations Nov. 2000
from less-trusted areas of the network. It is assumed that a
firewall will have much greater processing power for dismissing
bogus connection requests than end nodes.
8.3. Congestion Control and Transport Selection
The iSCSI protocol MUST be a good network citizen with proven
congestion control (as defined in RFC 2309). In addition, iSCSI
implementations MUST NOT use multiple connections as a means to
avoid transport-layer congestion control.
9. Definitions
Certain definitions are offered here, with references to the
original document where applicable, in order to clarify the
discussion of requirements. Definitions without references are the
work of the authors and reviewers of this document.
Logical Unit (LU): A target-resident entity that implements a device
model and executes SCSI commands sent by an application client [SAM-
2, sec. 3.1.50, p. 7].
Logical Unit Number (LUN): A 64-bit identifier for a logical unit
[SAM-2, sec. 3.1.52, p. 7].
SCSI Device: A device that is connected to a service delivery
subsystem and supports a SCSI application protocol [SAM-2, sec.
3.1.78, p. 9].
Service Delivery Port (SDP): A device-resident interface used by the
application client, device server, or task manager to enter and
retrieve requests and responses from the service delivery subsystem.
Synonymous with port (SAM-2 sec. 3.1.61) [SAM-2, sec. 3.1.89, p. 9].
Target: A SCSI device that receives a SCSI command and directs it to
one or more logical units for execution [SAM-2 sec. 3.1.97, p. 10].
Task: An object within the logical unit representing the work
associated with a command or a group of linked commands [SAM-2, sec.
3.1.98, p. 10].
Transaction: A cooperative interaction between two objects,
involving the exchange of information or the execution of some
service by one object on behalf of the other [SAM-2, sec. 3.1.109,
p. 10].
10. References
Krueger Informational Exp. May 2001 21
iSCSI Reqmnts and Design Considerations Nov. 2000
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 [SAM-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Architecture
Model -2 (SAM-2). T10 Project 1157-D. rev 13, 22 Mar 2000.
4 [SPC-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Primary
Commands 2 (SPC-2). T10 Project 1236-D. rev 18, 21 May 2000.
5 [CAM-3] ANSI NCITS. Dallas, William D., editor. Information
Technology - Common Access Method - 3 (CAM-3)). X3T10 Project
990D. rev 3, 16 Mar 1998.
6 [99-245r8] Hafner, Jim. A Detailed Proposal for Access Controls.
T10/99-245 revision 8, 26 Apr 2000.
7 [SPI-X] ANSI NCITS. SCSI Parallel Interface - X.
8 [FCP] ANSI NCITS. SCSI-3 Fibre Channel Protocol [ANSI
X3.269:1996].
9 [FCP-2] ANSI NCITS. SCSI-3 Fibre Channel Protocol - 2 [T10/1144-
D].
10 Paxon, V. End-to-end internet packet dynamics, IEEE Transactions
on Networking 7,3 (June 1999) pg 277-292.
11 Stone J., Partridge, C. When the CRC and TCP checksum disagree,
ACM Sigcomm (Sept. 2000).
12 [RFC1783] Berners-Lee, t., et.al.,"Uniform Resource Locators", RFC
1783, December 1994.
11. Acknowledgements
Special thanks to Julian Satran, IBM and David Black, EMC for their
extensive review comments.
12. Author's Addresses
Address comments to:
Marjorie Krueger
Hewlett-Packard Corporation
8000 Foothills Blvd
Roseville, CA 95747-5668, USA
Phone: +1 916 785-2656
Email: marjorie_krueger@hp.com
Randy Haagens
Hewlett-Packard Corporation
8000 Foothills Blvd
Krueger Informational Exp. May 2001 22
iSCSI Reqmnts and Design Considerations Nov. 2000
Roseville, CA 95747-5668, USA
Phone: +1 916 785-4578
Email: Randy_Haagens@hp.com
Costa Sapuntzakis
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134, USA
Phone: +1 408 525-5497
Email: csapuntz@cisco.com
Mark Bakke
Cisco Systems, Inc.
6450 Wedgwood Road
Maple Grove, MN 55311
Phone: +1 763 398-1054
Email: mbakke@cisco.com
Krueger Informational Exp. May 2001 23
iSCSI Reqmnts and Design Considerations Nov. 2000
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Krueger Informational Exp. May 2001 24