One document matched: draft-ietf-ips-iscsi-reqmts-01.txt
Differences from draft-ietf-ips-iscsi-reqmts-00.txt
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-01.txt March 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 a protocol to transport
the Small Computer Systems Interface (SCSI) protocol over the internet. 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 the iSCSI protocol should satisfy and the
design considerations guiding the iSCSI protocol development effort. In the
interest of timely adoption of the iSCSI protocol, this group has chosen 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.
Krueger Informational Expires May 2001 1
ISCSI Reqmnts and Design Considerations Nov. 2000
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
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........................................................2
2. iSCSI Design Considerations....................................................6
2.1. General Discussion.....................................................6
2.2. Performance/Cost.......................................................8
2.3. Framing................................................................9
2.4. High bandwidth, bandwidth aggregation.................................10
3. Ease of implementation/complexity of protocol.................................11
4. Reliability and Availability..................................................12
4.1. Recovery..............................................................12
5. Interoperability..............................................................12
5.1. Internet infrastructure...............................................12
5.2. SCSI..................................................................13
6. Security Considerations.......................................................14
6.1. Extensible Security...................................................14
6.2. Authentication........................................................14
6.3. Data Integrity........................................................15
6.4. Data Privacy..........................................................16
7. Management....................................................................16
7.1. Naming................................................................16
7.2. Topology Discovery....................................................17
8. Internet Accessibility........................................................17
8.1. Denial of Service.....................................................17
8.2. Firewalls and Proxy servers...........................................17
8.3. Congestion control and Transport Selection............................18
9. Virtualization................................................................18
10. Definitions..................................................................18
11. References...................................................................19
12. Acknowledgements.............................................................19
13. Author's Addresses...........................................................19
1. Summary of Requirements
>From section 2.1:
The iSCSI standard MUST specify how SCSI devices interact when attached to IP
networks.
The iSCSI standard MUST use TCP as its transport.
The iSCSI standard MUST not require modification to the current IP and Ethernet
infrastructure to support storage traffic.
Krueger Informational Exp. May 2001 2
ISCSI Reqmnts and Design Considerations Nov. 2000
>From section 2.2:
The iSCSI standard MUST allow implementations to equal or improve on the current
state of the art for SCSI interconnects:
MUST provide 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.
MUST permit zero-copy memory architectures.
MUST not impose complex operations on host software.
MUST be cost competitive with alternative storage networking technologies.
>From section 2.4:
iSCSI initiator SHOULD be able to send simultaneously to multiple
interfaces on the target through multiple paths through the network
iSCSI standard MUST operate over a single TCP connection
iSCSI standard MAY specify connection binding
initiators and targets MAY implement connection binding
>From section 3:
SHOULD keep the protocol simple.
SHOULD minimize optional features.
SHOULD negotiate optional features at session setup.
>From section 4:
SHOULD specify mechanisms to recover in a timely fashion from
failures on the initiator, target, or connecting infrastructure.
>From section 4.1:
MUST provide the ability to recover from a failed, hung, or timed-out TCP
connection, without the loss of the session between the initiator and target.
This recovery MUST particularly work for non-idempotent requests
SHOULD attempt to provide recovery in a timely fashion from initiator and target
reboots and failovers to other physical devices.
SHOULD also provide a method for sessions to be gracefully terminated and
restarted that can be initiated by either the initiator or target.
>From section 5:
iSCSI protocol document MUST be clear and unambiguous.
>From section 5.1:
MUST:
-- be compatible with both IPv4 and IPv6
Krueger Informational Exp. May 2001 3
ISCSI Reqmnts and Design Considerations Nov. 2000
-- 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.
>From section 5.2:
SHOULD comply with the requirements of the SCSI Architecture Model [SAM2].
SHOULD support all current SCSI command sets.
MUST support all SCSI-3 command sets and device types.
MUST be possible to create bridges from iSCSI to other SCSI interconnects (FCP,
etc.).
SHOULD track changes to SCSI and the SCSI Architecture Model.
must NOT require changes to the SCSI-3 command sets and SCSI client code except to
reflect lengthier iSCSI target names.
MUST reliably transport SCSI commands from the initiator to the target.
iSCSI MUST support FIFO delivery of SCSI commands from the initiator to the
target, to support SCSI Task Queuing.
>From section 6.1:
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:
MAY support various levels of authentication security.
The iSCSI protocol MUST support private authenticated login.
iSCSI authenticated login MUST be resilient against passive attacks.
must NOT preclude optional data origin authentication of its communications.
>From section 6.3:
should NOT preclude use of additional data integrity protection protocols (IPSec,
TLS).
MUST support the negotiation of a data integrity check format for use in CRC
generation.
SHOULD use separate CRCs for data and headers.
iSCSI data integrity negotiation scheme SHOULD be extensible to include other data
integrity CRC calculation methods.
Krueger Informational Exp. May 2001 4
ISCSI Reqmnts and Design Considerations Nov. 2000
>From section 6.3:
MAY use a data encryption protocol such as TLS or IPsec ESP to provide data
privacy between iSCSI endpoints.
>From section 7:
SHOULD be manageable using IP-based management protocols (eg. SNMP, RMI).
>From section 7.1:
iSCSI MUST support the naming architecture of SAM-2.
iSCSI protocol MUST provide a means of identifying ISCSI targets by a URL.
iSCSI protocol MUST provide a means of identifying ISCSI targets by a world-wide
unique identifier that is independent of the path on which it is found.
Standard internet lookup services SHOULD be used to resolve names.
iSCSI standard SHOULD deal with the complications of the new SCSI security
architecture.
iSCSI standard MUST support SCSI 3rd party operations
>From section 7.2:
iSCSI SHALL have no impact on the use of conventional IP network discovery
techniques
iSCSI SHALL provide some means of determining that a discovered IP endpoint is an
iSCSI node.
The iSCSI protocol MUST provide a method of discovering, given an IP end point and
its well-known port, the list of SCSI targets available to the requestor.
SCSI protocol-dependent techniques MUST be used for further discovery beyond the
iSCSI layer.
>From section 8.
The iSCSI protocol SHOULD be scrutinized for denial of service issues and they
should be addressed.
>From section 8.2
Any login or connect command MUST include the full iSCSI address of the target.
The iSCSI protocol's use of IP addresses and TCP ports SHOULD be firewall
friendly.
>From section 8.3
Krueger Informational Exp. May 2001 5
ISCSI Reqmnts and Design Considerations Nov. 2000
The iSCSI protocol MUST be a good network citizen with TCP-compatible congestion
control (as defined in RFC 2309).
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 through the SCSI parallel bus or through Fibre Channel. File-oriented
storage controllers have supported the NFS and/or CIFS protocols, and have been
attached directly to IP networks such as Ethernet.
The IP infrastructure offers compelling advantages for volume/block-oriented
storage attachment compared to current approaches. It offers the opportunity to
take advantage of the cost/performance benefits provided by competition in the
internet marketplace. This reduces the cost of storage infrastructure by:
-- Increasing performance (market driven by networking demand)
-- Offers richer array of management, security and QoS solutions
-- Economies arising from the need to install and operate only single type of
network
In addition, mapping SCSI over IP 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)
-- 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 MUST support the following topologies:
-- Point-to-point direct connections
-- 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
Local-area storage networks will be built using Ethernet LAN switches. These
networks may be dedicated to storage, or shared with traditional Ethernet uses, as
determined by cost, performance, administration, and security considerations. In
Krueger Informational Exp. May 2001 6
ISCSI Reqmnts and Design Considerations Nov. 2000
the local area, TCP's adaptive retransmission timers will provide for automatic
and rapid error detection and recovery, compared to alternative transport
protocols.
IP LAN-WAN routers will 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, TCP end-to-end will avoid the need for specialized
equipment for protocol conversion, ensure data reliability, cope with network
congestion, and automatically adapt retransmission strategies to WAN delays.
The full realization of iSCSI will involve the following elements:
(1) Completion of Requirements (this document) and Specification documents;
(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 as MIBs, XML
schemas, etc.
Products will 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 will perform full-stack
processing of a complete SCSI task, analogous to today's SCSI and Fibre Channel
HBAs. They typically also will support all host protocols that use TCP, including
NFS, CIFS and HTTP.
The iSCSI protocol must NOT require modifications to the current IP and Ethernet
infrastructure to support storage traffic over TCP. Nevertheless, the performance
and security requirements of storage will create opportunities for improvement in
security protocols and QoS implementations. The addition of storage traffic to
local and wide-area internets (and even to the public Internet) may introduce
increased requirements for traffic monitoring and engineering in those
environments.
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 will benefit from the
high performance/cost of IP equipment and a unified management architecture,
compared to alternative means of building storage networks. As security and QoS
evolve, it may become reasonable to build combined networks with shared
infrastructure; nevertheless, it is likely that sophisticated users will choose to
keep their storage subnetworks isolated to afford the best control of security and
QoS.
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
Krueger Informational Exp. May 2001 7
ISCSI Reqmnts and Design Considerations Nov. 2000
charter, several transport alternatives may be considered. Our initial work
focuses on TCP, and this requirements document is restricted to that domain of
interest. At the current time, the working group does not seek a more generic
requirements statement that would justify the choice of TCP (or another protocol)
as transport, since the merits of using TCP are readily evident to the working
group participants.
2.2. Performance/Cost
EDITORS NOTE: Performance/Cost is frequently, but inaccurately, referred to as
Cost/Performance. The Performance/Cost formulation is the correct representation,
demonstrating that increasing Performance/Cost is good.
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:
iSCSI implementations must be cost competitive with Fibre Channel, etc. to be
adopted by vendors and the user community.
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.
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 MUST permit "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 (0 copy iSCSI):
This is an important implementation goal. In an iSCSI system, each of the end
nodes (for example host computer and storage controller) has ample memory; but the
intervening nodes (NIC, switches) do not. We contemplate a WAN-scale
retransmission requirement of 25 MB (1 Gbps) or 250 MB (10 Gbps, see Framing
Krueger Informational Exp. May 2001 8
ISCSI Reqmnts and Design Considerations Nov. 2000
discussion). Therefore, it must not be necessary for intervening nodes to buffer
data.
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). 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 (SCSI)
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. That assumes that the receiver will parse from the beginning of the
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 "0 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.
First, vendors are producing network processing hardware that offloads network
protocols to hardware solutions to achieve higher data rates. The concept of "0
copy" seeks to store blocks of data in appropriate memory locations (aligned)
directly off the wire, even in when data is reordered due to packet loss. This is
necessary to drive actual data rates of 10 Gigabits and beyond.
Krueger Informational Exp. May 2001 9
ISCSI Reqmnts and Design Considerations Nov. 2000
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, tens of megabytes of outstanding
requests from the application are needed. 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.
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 (we need to consider round-trip delay 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, we would be
obliged to catch 250 MB of data into an anonymous buffer before we could resume
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 "accelerated processing
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
History has shown that any single link can be saturated by storage traffic.
Scientific data applications, asynchronous and synchronous data replication are
examples of applications that have pushed and continue to push the limits of
throughput.
The iSCSI standard MUST allow the initiator and target to use multiple network
interfaces and multiple paths through the network for increased 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 latency of the operation.
To allow an initiator to maintain 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).
Krueger Informational Exp. May 2001 10
ISCSI Reqmnts and Design Considerations Nov. 2000
The iSCSI standard MAY provide a FIFO transport of SCSI commands, even when
commands are sent along different paths. This FIFO transport mechanism MAY wish to
minimize the amount of communication necessary across multiple adapters doing
transport off-load.
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 use
stop-and-wait to do ordered updates.
Another approach might be for the 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 consensus of the working group is that support for connection binding is NOT a
requirement for initiators and targets. (ref e-mail of David Black to ips
reflector on Oct 11, 2000) There has been no explicit decision on whether the
protocol is required to support connection binding.
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.
Another point in the design space for connection binding has to do with the data
transfer associated with a SCSI command. The data transfer is said to have
allegiance to the SCSI command if it occurs on the same connection on which the
command was sent. A data transfer can also potentially have allegiance to a
specific connection, even if it is different from the command was sent (perhaps
the connection is specified in the command request). Finally, a data transfer can
have no allegiance and appear across any number of connections.
The question of symmetric or asymmetric has yet to be resolved by the IPS working
group. The symmetric approach potentially requires less communication between the
interfaces and has simpler recovery semantics in the case of a connection failure.
The asymmetric approach can simplify some aspects of the protocol and potentially
yields greater throughput. The symmetric approach with data/command connection
allegiance is currently being pursued in the iSCSI protocol specification.
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
Krueger Informational Exp. May 2001 11
ISCSI Reqmnts and Design Considerations Nov. 2000
fulfill the requirements of the interconnect effort, 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 SHOULD allow for feature negotiation
at session establishment (login) and provide for rejection when an implementation
does not support a requested feature.
4. Reliability and Availability
ISCSI protocol design, while placing an emphasis on simplicity, SHOULD lead to
timely recovery from failure of initiator, target, or connecting internet
infrastructure (cabling, data path equipment such as routers, etc). This would
provide a basis for layered technologies like high availability and clustering.
The protocol specification 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".
4.1. Recovery
The iSCSI protocol MUST provide the ability to recover from a failed, hung, or
timed-out TCP connection, without the loss of the session between the initiator
and target. This recovery MUST particularly work for non-idempotent requests,
such as operations on tape drives. If all TCP connections for a session fail, and
no connections can be established, the iSCSI session MUST be aborted.
The iSCSI protocol SHOULD attempt to provide recovery in a timely fashion from
initiator and target reboots and failovers to other physical devices.
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 fail over an initiator or target, or to
gracefully reset a target after upgrading software or performing other maintenance
tasks.
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
Krueger Informational Exp. May 2001 12
ISCSI Reqmnts and Design Considerations Nov. 2000
-- 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
5.2. SCSI
Since iSCSI is a SCSI transport, the iSCSI standard SHOULD comply with the
requirements of the SCSI Architecture Model [SAM2] and SHOULD support all current
SCSI command sets. Furthermore, it MUST be possible to create bridges from iSCSI
to other SCSI interconnects (FCP, etc.).
The iSCSI protocol SHOULD track changes to SCSI and the SCSI Architecture Model.
iSCSI is a new SCSI "transport" [SAM2]. As a mapping of SCSI over TCP, iSCSI
requires interaction with both T10 and IETF. However, a stated requirement
(below) is that iSCSI shall have no impact on T10 architecture or command sets.
Collaboration with T10 will be necessary to achieve this requirement.
Collaboration with T10 concerns three phases of T10 activity:
(1) Past. For T10 work already completed (documented in a T10 standards
publication) the IPS working group will seek assistance in properly
interpreting those standards;
(2) Present. For T10 work that is ongoing, or recently completed (but not
widely published), the IPS working group will seek review of our work by
individuals active in T10, and/or the participation of those individuals in
the IETF process;
(3) Future. For compatibility with future T10 work, it is essential that iSCSI
be a legitimate and recognized "SCSI transport. SCSI command standards
should evolve within the context of all SCSI transports.
Storage attachment to IP networks will engender an unprecedented potential for
device sharing. This alone may impact future T10 work.
The iSCSI protocol MUST support 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.
The iSCSI protocol must NOT require changes to the SCSI-3 command sets and SCSI
client code except to reflect lengthier iSCSI target names and potentially
lengthier timeouts.
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 talk to
SCSI-X devices; so that SCSI-X devices can talk to each other over an iSCSI
network; and so that SCSI-X hosts can talk to iSCSI devices (where SCSI-X refers
Krueger Informational Exp. May 2001 13
ISCSI Reqmnts and Design Considerations Nov. 2000
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 packet drop, duplication, corruption, stale packets, and re-ordering.
iSCSI MUST support FIFO delivery of SCSI commands from the initiator to the
target, to support SCSI Task Queuing.
6. Security Considerations
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 privacy is considered critical in enterprises
and many IP networks may have access holes, organizations will want to protect
their IP SCSI resources.
Krueger Informational Exp. May 2001 14
ISCSI Reqmnts and Design Considerations Nov. 2000
The iSCSI authenticated login MUST be resilient against passive attacks since many
IP networks are vulnerable to packet inspection. Simple, US-exportable techniques
exist to satisfy this requirement.
In addition, the iSCSI protocol must NOT preclude optional data origin
authentication of its communications. Data origin authentication is critical since
IP networks are vulnerable to source spoofing, where a malicious third party can
pretend to send packets from the initiatorĘs IP address.
These requirements should be met using a variety of internet protocols, such as
IPsec or TLS. The endpoints may negotiate the authentication method, optionally
none.
6.3. Data Integrity
-- The iSCSI protocol should NOT preclude use of additional data integrity
protection protocols (IPSec, TLS).
-- The iSCSI protocol MUST support the negotiation of a data integrity check
format for use in CRC generation.
-- The iSCSI protocol SHOULD use separate CRCs for data and headers. Two header
CRCs, one for invariant portions of the header (addresses) and one for the
variant portion would provide the strongest integrity check.
-- The iSCSI data integrity negotiation scheme SHOULD be extensible to include
other data integrity CRC calculation methods.
The iSCSI protocol MUST provide the ability to select data integrity check formats
appropriate for the environment in which it is to run. For example, a layer 2
network (such as Ethernet) uses a 32 bit CRC to protect each IP packet. When
running in this environment, it is likely that no additional data integrity
mechanisms need be provided by iSCSI, so a data integrity scheme of "none" might
be used.
However, in a L3 or L4 routed network, the physical layer CRC is removed and
replaced at each router, and TCP data streams are protected only by the 16-bit TCP
checksum. In some applications and networks, this may be acceptable, but SCSI
data requires a stronger checksum. A particular instance of iSCSI could rely on
data integrity checks from a security layer such as IPsec, but IPSec presents
difficulties across iSCSI proxies or gateways.
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 should include a CRC
or other 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.
Krueger Informational Exp. May 2001 15
ISCSI Reqmnts and Design Considerations Nov. 2000
6.4. Data Privacy
Block storage is used for storing sensitive information, where data privacy 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, link encryption may be desired to provide an extra
assurance of privacy. An iSCSI implementation MAY use a data encryption protocol
such as TLS or IPsec ESP to provide data privacy between iSCSI endpoints.
7. Management
The iSCSI protocol layer should be manageable using IP-based management protocols
(eg. SNMP, RMI).
The iSCSI protocol document will not define the management architecture for iSCSI
within the network infrastructure.
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.
The iSCSI protocol MUST provide a means of identifying iSCSI targets by a flexible
path address (URL), where the path is the combination of a DNS name or IP address,
a TCP port, and an optional ASCII path name identifying the target.
The iSCSI protocol MUST provide a means of identifying iSCSI targets by a world-
wide unique identifier (WWUI), that is independent of the path on which it is
found. This will be used to correlate alternate paths to the same device.
Note that LU names are discovered through SCSI-level inquiries, and are not just
for Fibre Channel. There is nothing to prevent iSCSI (or parallel SCSI) from
implementing the LU WWN. As such, this is outside the scope of the iSCSI protocol
specification.
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 the 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,
Krueger Informational Exp. May 2001 16
ISCSI Reqmnts and Design Considerations Nov. 2000
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.
7.2. Topology Discovery
iSCSI MUST have no impact on the use of conventional IP network discovery
techniques. Various network management platforms have ways of discovering IP
addresses. These techniques will be used, and will find all of the IP end points
that contain iSCSI nodes.
The iSCSI protocol shall provide appropriate discovery mechanisms which scale from
adding single devices to an iSCSI-internal storage subsystem, up to the deployment
of multi-customer, multi-utility storage outsourcing environments.
The IPS working group should recommend some means of determining whether an iSCSI
service is available through an IP address. It is 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.
The iSCSI protocol may provide a method of discovering, given an IP end point on
its well-known port, the list of SCSI targets available to the requestor. These
targets should either be path addresses, or WWUIs. The use of this discovery
service should be optional.
SCSI protocol-dependent techniques shall 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, so the commands
associated with this process will also work over iSCSI.
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. Firewalls and Proxy servers
During the login phase, any login or connect command MUST include the full iSCSI
address of the target to which the initiator wishes to connect. This includes the
IP Address (or DNS name), TCP port number, and iSCSI PATH (target name), and
allows an initiator to connect to a target through an iSCSI proxy server.
The iSCSI protocolĘs use of IP addressing and TCP port numbers MUST be firewall
friendly. This probably means that all connection requests should be addressed to
Krueger Informational Exp. May 2001 17
ISCSI Reqmnts and Design Considerations Nov. 2000
a specific, well-known TCP port. That way, firewalls can filter based on source
and destination IP addresses, and destination (target) port number. The source
(initiator) port number should also be well-known for the initial TCP connection.
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 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 do the 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. Virtualization
Virtualization of targets and LUNs is generally handled by intelligent gateways,
storage controllers, or other devices. Many vendors, especially those that build
storage devices, include very advanced virtualization features that are beyond the
scope of a SCSI transport layer to define, and are usually closely guarded as
intellectual property.
Requiring the iSCSI protocol to work within an environment that includes proxies
and gateways (see earlier requirements) will provide a SCSI transport that will
enable vendors to add their own virtualization features without breaking the
protocol or causing interoperability problems.
10. 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].
Krueger Informational Exp. May 2001 18
ISCSI Reqmnts and Design Considerations Nov. 2000
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]. [A transaction seems to be a smaller unit
than a task.]
11. References
1 [SAM-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Architecture Model -2 (SAM-
2). T10 Project 1157-D. rev 13, 22 Mar 2000.
2 [SPC-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Primary Commands - 2 (SPC-
2). T10 Project 1236-D. rev 18, 21 May 2000.
3 [CAM-3] ANSI NCITS. Dallas, William D., editor. Information Technology -
Common Access Method - 3 (CAM-3)). X3T10 Project 990D. rev 3, 16 Mar 1998.
4 [99-245r8] Hafner, Jim. A Detailed Proposal for Access Controls. T10/99-245
revision 8, 26 Apr 2000.
5 [SPI-X] ANSI NCITS. SCSI Parallel Interface - X.
6 [FCP] ANSI NCITS. SCSI-3 Fibre Channel Protocol [ANSI X3.269:1996]
7 [FCP-2] ANSI NCITS. SCSI-3 Fibre Channel Protocol - 2 [T10/1144-D]
12. Acknowledgements
<TBD>
13. 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
Krueger Informational Exp. May 2001 19
ISCSI Reqmnts and Design Considerations Nov. 2000
8000 Foothills Blvd
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 20
ISCSI Reqmnts and Design Considerations Nov. 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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
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
Krueger Informational Exp. May 2001 21 | PAFTECH AB 2003-2026 | 2026-04-19 18:49:07 |