As per Relevance of the word transport, we have this rfc below:
Network Working Group M.
Request for Comments: 3347 R.
Category: Informational Hewlett-Packard
C.
M.
Cisco
July 2002
Small Computer Systems Interface protocol over the Internet (iSCSI
Requirements and Design
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document specifies the requirements iSCSI and its
infrastructure should satisfy and the design considerations
the iSCSI protocol development efforts. In the interest of
adoption of the iSCSI protocol, the IPS group has chosen to focus
first version of the protocol to work with the existing
architecture and commands, and the existing TCP/IP transport layer
Both these protocols are widely-deployed and well-understood.
thought is that using these mature protocols will entail a minimum
new invention, the most rapid possible adoption, and the
compatibility with Internet architecture, protocols, and equipment
Conventions used in this
This document describes the requirements for a protocol design,
does not define a protocol standard. Nevertheless, the key
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
are to be interpreted as described in RFC-2119 [2].
Krueger, et al. Informational [Page 1]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
Table of
1. Introduction.................................................2
2. Summary of Requirements......................................3
3. iSCSI Design Considerations..................................7
3.1. General Discussion...........................................7
3.2. Performance/Cost.............................................9
3.3. Framing.....................................................11
3.4. High bandwidth, bandwidth aggregation.......................13
4. Ease of implementation/complexity of protocol...............14
5. Reliability and Availability................................15
5.1. Detection of Data Corruption................................15
5.2. Recovery....................................................15
6. Interoperability............................................16
6.1. Internet infrastructure.....................................16
6.2. SCSI........................................................16
7. Security Considerations.....................................18
7.1. Extensible Security.........................................18
7.2. Authentication..............................................18
7.3. Data Integrity..............................................19
7.4. Data Confidentiality........................................19
8. Management..................................................19
8.1. Naming......................................................20
8.2. Discovery...................................................21
9. Internet Accessibility......................................21
9.1. Denial of Service...........................................21
9.2. NATs, Firewalls and Proxy servers...........................22
9.3. Congestion Control and Transport Selection..................22
10. Definitions.................................................22
11. References..................................................23
12. Acknowledgements............................................24
13. Author's Addresses..........................................25
14. Full Copyright Statement....................................26
1.
The IP Storage Working group is chartered with
comprehensive technology to transport block storage data over
protocols. This effort includes a protocol to transport the
Computer Systems Interface (SCSI) protocol over the Internet (iSCSI).
The initial version of the iSCSI protocol will define a mapping
SCSI transport protocol over TCP/IP so that SCSI storage
(principally disk and tape arrays and libraries) can be attached
IP networks, notably Gigabit Ethernet (GbE) and 10 Gigabit
(10 GbE).
Krueger, et al. Informational [Page 2]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
The iSCSI protocol is a mapping of SCSI to TCP, and constitutes
"SCSI transport" as defined by the ANSI T10 document SCSI SAM-2
document [SAM2, p. 3, "Transport Protocols"].
2. Summary of
The iSCSI standard
From section 3.2 Performance/Cost
MUST allow implementations to equal or improve on the
state of the art for SCSI interconnects
MUST enable cost competitive implementations
SHOULD minimize control overhead to enable low
communications
MUST provide high bandwidth and bandwidth aggregation
MUST have low host CPU utilizations, equal to or better
current technology
MUST be possible to build I/O adapters that handle the entire
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 (
connections) at the device interfaces and within the
fabric
From section 3.4 High Bandwidth/Bandwidth Aggregation
MUST operate over a single TCP connection
SHOULD support 'connection binding', and it MUST be optional
implement
From section 4 Ease of Implementation/Complexity of Protocol
SHOULD keep the protocol simple
SHOULD minimize optional features
Krueger, et al. Informational [Page 3]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
MUST specify feature negotiation at session establishment (login).
MUST operate correctly when no optional features are negotiated
well as when individual option negotions are unsuccessful
From section 5.1 Detection of Data Corruption
MUST support a data integrity check format for use in
generation
MAY use separate digest for data and headers
iSCSI header format SHOULD be extensible to include other
integrity digest calculation methods
From section 5.2 Recovery
MUST specify mechanisms to recover in a timely fashion
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
highly available storage configurations
SHOULD provide a method for sessions to be gracefully
and restarted that can be initiated by either the initiator
target
From section 6 Interoperability
iSCSI protocol document MUST be clear and unambiguous
From section 6.1 Internet Infrastructure
MUST
-- be compatible with both IPv4 and IPv
-- use TCP connections conservatively, keeping in mind there
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/
implementations
MUST be designed to allow future substitution of SCTP (for TCP)
an IP transport protocol with minimal changes to iSCSI
operation, protocol data unit (PDU) structures and formats
Krueger, et al. Informational [Page 4]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
From section 6.2 SCSI
Any feature SAM2 requires in a valid transport mapping MUST
specified by iSCSI
MUST specify strictly ordered delivery of SCSI commands over
iSCSI session between an initiator/target pair
The command ordering mechanism SHOULD seek to minimize the
of communication necessary across multiple adapters
transport off-load
MUST specify for each feature whether it is OPTIONAL,
or REQUIRED to implement and/or use
MUST NOT require changes to the SCSI-3 command sets and
client code except except where SCSI specifications point
"transport dependent" fields and behavior
SHOULD track changes to SCSI and the SCSI Architecture Model
MUST be capable of supporting all SCSI-3 command sets and
types
SHOULD support ACA implementation
MUST allow for the construction of gateways to other
MUST reliably transport SCSI commands from the initiator to
target
MUST correctly deal with iSCSI packet drop, duplication
corruption, stale packets, and re-ordering
From section 7.1 Extensible Security
SHOULD require minimal configuration and overhead in the
operation
MUST provide for strong authentication when increased security
required
SHOULD allow integration of new security mechanisms
breaking backwards compatible operation
Krueger, et al. Informational [Page 5]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
From section 7.2 Authentication
MAY support various levels of authentication security
MUST support private authenticated login
iSCSI authenticated login MUST be resilient against attacks
MUST support data origin authentication of its communications
data origin authentication MAY be optional to use
From section 7.3 Data Integrity
SHOULD NOT preclude use of additional data integrity
protocols (IPSec, TLS).
From section 7.4 Data Confidentiality
MUST provide for the use of a data encryption protocol such as
or IPsec ESP to provide data confidentiality between
From section 8 Management
SHOULD be manageable using standard IP-based management protocols
iSCSI protocol document MUST NOT define the
architecture for iSCSI, or make explicit references to
objects such as MIB variables
From section 8.1 Naming
MUST support the naming architecture of SAM-2. The means by
an iSCSI resource is located MUST use or extend existing
standard resource location methods
MUST provide a means of identifying iSCSI targets by a
identifier that is independent of the path on which it is found
The format for the iSCSI names MUST use existing
authorities
An iSCSI name SHOULD be a human readable string in
international character set encoding
Standard Internet lookup services SHOULD be used to resolve
names
Krueger, et al. Informational [Page 6]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
SHOULD deal with the complications of the new SCSI
architecture
iSCSI naming architecture MUST address support of SCSI 3rd
operations such as EXTENDED COPY
From section 8.2 Discovery
MUST have no impact on the use of current IP network
techniques
MUST provide some means of determining whether an iSCSI service
available through an IP address
SCSI protocol-dependent techniques SHOULD be used for
discovery beyond the iSCSI layer
MUST provide a method of discovering, given an IP end point on
well-known port, the list of SCSI targets available to
requestor. The use of this discovery service MUST be optional
From section 9 Internet Accessability
SHOULD be scrutinized for denial of service issues and they
be addressed
From section 9.2 Firewalls and Proxy
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 9.3 Congestion Control and Transport
MUST be a good network citizen with TCP-compatible
control (as defined in [RFC2914]).
iSCSI implementations MUST NOT use multiple connections as a
to avoid transport-layer congestion control
3. iSCSI Design
3.1. General
Traditionally, storage controllers (e.g., disk array controllers
tape library controllers) have supported the SCSI-3 protocol and
been attached to computers by SCSI parallel bus or Fibre Channel
Krueger, et al. Informational [Page 7]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
The IP infrastructure offers compelling advantages for volume
block-oriented storage attachment. It offers the opportunity to
advantage of the performance/cost benefits provided by competition
the Internet marketplace. This could reduce the cost of
network infrastructure by providing economies arising from the
to install and operate only a single type of network
In addition, the IP protocol suite offers the opportunity for a
array of management, security and QoS solutions. Organizations
initially choose to operate storage networks based on iSCSI that
independent of (isolated from) their current data networks except
secure routing of storage management traffic. These
anticipated benefits from the high performance/cost of IP
and the opportunity for a unified management architecture.
security and QoS evolve, it becomes reasonable to build
networks with shared infrastructure; nevertheless, it is likely
sophisticated users will choose to keep their storage sub-
isolated to afford the best control of security and QoS to ensure
high-performance environment tuned to storage traffic
Mapping SCSI over IP also provides
-- Extended distance
-- Connectivity to "carrier class" services that support
The following applications for iSCSI are contemplated
-- Local storage access, consolidation, clustering and pooling (
in the data center
-- Network client access to remote storage (eg. a "storage
provider")
-- Local and remote synchronous and asynchronous mirroring
storage
-- Local and remote backup and
iSCSI will support the following topologies
-- Point-to-point direct
-- Dedicated storage LAN, consisting of one or more LAN
-- Shared LAN, carrying a mix of traditional LAN traffic
storage
-- LAN-to-WAN extension using IP routers or carrier-provided "
Datatone
-- Private networks and the public
IP LAN-WAN routers may be used to extend the IP storage network
the wide area, permitting remote disk access (as for a
utility), synchronous and asynchronous remote mirroring, and
Krueger, et al. Informational [Page 8]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
backup and restore (as for tape vaulting). In the WAN, using
end-to-end avoids the need for specialized equipment for
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
implementations
(2) Development of Ethernet storage NICs and related driver
protocol software; [NOTE: high-speed applications of iSCSI
expected to require significant portions of the iSCSI/TCP/
implementation in hardware to achieve the necessary throughput.]
(3) Development of compatible storage controllers;
(4) The likely development of translating gateways to
connectivity between the Ethernet storage network and the
Channel and/or parallel-bus SCSI domains
(5) Development of specifications for iSCSI device management
as MIBs, LDAP or XML schemas, etc
(6) Development of management and directory service applications
support a robust SAN infrastructure
Products could initially be offered for Gigabit Ethernet attachment
with rapid migration to 10 GbE. For performance competitive
alternative SCSI transports, it will be necessary to implement
performance path of the full protocol stack in hardware. These
storage NICs might perform full-stack processing of a complete
task, analogous to today's SCSI and Fibre Channel HBAs, and
also support all host protocols that use TCP (NFS, CIFS, HTTP, etc).
The charter of the IETF IP Storage Working Group (IPSWG)
the broad goal of mapping SCSI to IP using a transport that
proven congestion avoidance behavior and broad implementation on
variety of platforms. Within that broad charter, several
alternatives may be considered. Initial IPS work focuses on TCP,
this requirements document is restricted to that domain of interest
3.2. Performance/
In general, iSCSI MUST allow implementations to equal or improve
the current state of the art for SCSI interconnects. This
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
protocol MUST enable cost competitive implementations when
to other SCSI transports (Fibre Channel).
Krueger, et al. Informational [Page 9]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
Low delay communication
Conventional storage access is of a stop-and-wait remote
call type. Applications typically employ very little pipelining
their storage accesses, and so storage access delay directly
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
many storage accesses complete almost instantly, and so the delay
the interconnect can have a high relative impact on
performance. When stop-and-wait IO is used, the delay of
interconnect will affect performance. The iSCSI protocol
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
implementation goals to be realized
(1) iSCSI MUST make it possible to build I/O adapters that handle
entire SCSI task, as alternative SCSI transport
do
(2) The protocol SHOULD permit direct data placement ("zero-copy
memory architectures, where the I/O adapter reads or writes
memory exactly once per disk transaction
(3) The protocol SHOULD NOT impose complex operations on the
software, which would increase host instruction path
relative to alternatives
Direct data placement (zero-copy iSCSI):
Direct data placement refers to iSCSI data being placed directly "
the wire" into the allocated location in memory with no
copies. Direct data placement significantly reduces the memory
and I/O bus loading in the endpoint systems, allowing
performance. It reduces the memory required for NICs,
reducing the cost of these solutions
This is an important implementation goal. In an iSCSI system,
of the end nodes (for example host computer and storage controller
should have ample memory, but the intervening nodes (NIC, switches
typically will not
Krueger, et al. Informational [Page 10]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
High bandwidth, bandwidth aggregation
The bandwidth (transfer rate, MB/sec) supported by
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
spindles, speed of interconnects).
The iSCSI protocol MUST provide for full utilization of
link bandwidth. The protocol MUST also allow an implementation
exploit parallelism (multiple connections) at the device
and within the interconnect fabric
The next two sections further discuss the need for direct
placement and high bandwidth
3.3.
Framing refers to the addition of information in a header, or
data stream to allow implementations to locate the boundaries of
iSCSI protocol data unit (PDU) within the TCP byte stream. There
two technical requirements driving framing: interfacing needs,
accelerated processing needs
A framing solution that addresses the "interfacing needs" of
iSCSI protocol will facilitate the implementation of a message-
upper layer protocol (iSCSI) on top of an underlying byte
protocol (TCP). Since TCP is a reliable transport, this can
accomplished by including a length field in the iSCSI header.
the protocol frame assumes that the receiver will parse from
beginning of the TCP data stream, and never make a mistake (
alignment on packet headers).
The other technical requirement for framing, "
processing", stems from the need to handle increasingly higher
rates in the physical media interface. Two needs arise from
data rates
(1) LAN environment - NIC vendors seek ways to provide "zero-copy
methods of moving data directly from the wire into
buffers
(2) WAN environment- the emergence of high bandwidth, high latency
low bit error rate physical media places huge
requirements on the physical interface solutions
Krueger, et al. Informational [Page 11]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
First, vendors are producing network processing hardware
offloads network protocols to hardware solutions to achieve
data rates. The concept of "zero-copy" seeks to store blocks of
in appropriate memory locations (aligned) directly off the wire,
when data is reordered due to packet loss. This is necessary
drive actual data rates of 10 Gigabit/sec and beyond
Secondly, in order for iSCSI to be successful in the WAN arena
must be possible to operate efficiently in high bandwidth, high
networks. The emergence of multi-gigabit IP networks with
in the tens to hundreds of milliseconds presents a challenge.
fill such large pipes, it is necessary to have tens of megabytes
outstanding requests from the application. In addition,
protocols potentially require tens of megabytes at the
layer to deal with buffering for reassembly of data when packets
received out-of-order
In both cases, the issue is the desire to minimize the amount
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
world at the equator. Ignore additional distance due to
routing. Ignore repeater and switching delays; consider only
speed-of-light delay of 5 microsec/km. The circumference of
globe at the equator is approx. 40000 km (round-trip delay must
considered to keep the pipe full). 10 Gb/sec x 40000 km x 5
microsec/km x B / 8b = 250 MB]. In a conventional
implementation, loss of a TCP segment means that stream
MUST stop until that segment is recovered, which takes at least
time of to accomplish. Following the
above, an implementation would be obliged to catch 250 MB of
into an anonymous buffer before resuming stream processing; later
this data would need to be moved to its proper location.
proponents of iSCSI seek some means of putting data directly where
belongs, and avoiding extra data movement in the case of
drop. This is a key concept in understanding the debate
framing methodologies
The framing of the iSCSI protocol impacts both the "
needs" and the "accelerated processing needs", however,
including a length in a header may suffice for the "
needs", it will not serve the direct data placement needs.
framing mechanism developed should allow resynchronization of
boundaries even in the case where a packet is temporarily missing
the incoming data stream
Krueger, et al. Informational [Page 12]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
3.4. High bandwidth, bandwidth
At today's block storage transport throughput, any single link can
saturated by the volume of storage traffic. Scientific
applications and data replication are examples of
applications that push the limits of throughput
Some applications, such as log updates, streaming tape,
replication, require ordering of updates and thus ordering of
commands. An initiator may maintain ordering by waiting for
update to complete before issuing the next (a.k.a.
updates). However, the throughput of synchronous updates
inversely with increases in network distances
For greater throughput, the SCSI task queuing mechanism allows
initiator to have multiple commands outstanding at the
simultaneously and to express ordering constraints on the
of those commands. The task queuing mechanism is only effective
the commands arrive at the target in the order they were presented
the initiator (FIFO order). The iSCSI standard must provide
ordered transport of SCSI commands, even when commands are sent
different network paths (see Section 5.2 SCSI). This is referred
as "command ordering".
The iSCSI protocol MUST operate over a single TCP connection
accommodate lower cost implementations. To enable higher
storage devices, the protocol should specify a means to
operation over multiple connections while maintaining the behavior
a single SCSI port. This would allow the initiator and target to
multiple network interfaces and multiple paths through the
for increased throughput. There are a few potential ways to
the multiple path and ordering requirements
A popular way to satisfy the multiple-path requirement is to have
driver above the SCSI layer instantiate multiple copies of the
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
completion of each request (stop-and-wait) to ensure ordered updates
Another approach might be for iSCSI protocol to use
instances of its underlying transport (e.g. TCP). The iSCSI
would make these independent transport instances appear as one
transport instance and maintain the ability to do ordered
command queuing. The document will refer to this technique
"connection binding" for convenience
Krueger, et al. Informational [Page 13]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
The iSCSI protocol SHOULD support connection binding, and it MUST
optional to implement
In the presence of connection binding, there are two ways to
features to connections. In the symmetric approach, all
connections are identical from a feature standpoint. In
asymmetric model, connections have different features. For example
some connections may be used primarily for data transfers
others are used primarily for SCSI commands
Since the iSCSI protocol must support the case where there was
one transport connection, the protocol must have command, data,
status travel over the same connection
In the case of multiple connections, the iSCSI protocol must keep
command and its associated data and status on the same
(connection allegiance). Sending data and status on the
connection is desirable because this guarantees that status
received after the data (TCP provides ordered delivery). In the
where each connection is managed by a separate processor,
decreases the need for inter-processor communication. This
approach is a natural extension of the single connection approach
An alternate approach that was extensively discussed involved
all commands on a single connection and the associated data
status on a different connection (asymmetric approach). In
scheme, the transport ensures the commands arrive in order.
protocol on the data and status connections is simpler,
lending itself to a simpler realization in hardware.
disadvantage of this approach is that the recovery procedure
different if a command connection fails vs. a data connection.
argued that this approach would require greater inter-
communication when connections are spread across processors
The reader may reference the mail archives of the IPS mailing
between June and September of 2000 for extensive discussions
symmetric vs asymmetric connection models
4. Ease of implementation/complexity of
Experience has shown that adoption of a protocol by the
community is inversely proportional to its complexity. In addition
the simpler the protocol, the easier it is to diagnose problems.
designers of iSCSI SHOULD strive to fulfill the requirements of
creating a SCSI transport over IP, while keeping the protocol
simple as possible
Krueger, et al. Informational [Page 14]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
In the interest of simplicity, iSCSI SHOULD minimize
features. When features are deemed necessary, the protocol
specify feature negotiation at session establishment (login).
iSCSI transport MUST operate correctly when no optional features
negotiated as well as when individual option negotiations
unsuccessful
5. Reliability and
5.1. Detection of Data
There have been several research papers that suggest that the
checksum calculation allows a certain number of bit errors to
undetected [10] [11].
In order to protect against data corruption, the iSCSI protocol
support a data integrity check format for use in digest generation
The iSCSI protocol MAY use separate digests for data and headers.
an iSCSI proxy or gateway situation, the iSCSI headers are
and re-built, and the TCP stream is terminated on either side.
means that even the TCP checksum is removed and recomputed within
gateway. To ensure the protection of commands, data, and status
iSCSI protocol MUST include a CRC or other digest mechanism that
computed on the SCSI data block itself, as well as on each
and status message. Since gateways may strip iSCSI headers
rebuild them, a separate header CRC is required. Two header digests
one for invariant portions of the header (addresses) and one for
variant portion would provide protection against changes to
of the header that should never be changed by middle boxes (eg
addresses).
The iSCSI header format SHOULD be extensible to include other
calculation methods
5.2.
The SCSI protocol was originally designed for a parallel
transport that was highly reliable. SCSI applications tend to
that transport errors never happen, and when they do,
application recovery tends to be expensive in terms of time
computational resources
iSCSI protocol design, while placing an emphasis on simplicity,
lead to timely recovery from failure of initiator, target,
connecting network infrastructure (cabling, data path equipment
as routers, etc).
Krueger, et al. Informational [Page 15]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
iSCSI MUST specify recovery methods for non-idempotent requests,
as operations on tape drives
The iSCSI protocol error recover mechanism SHOULD take into
fail-over schemes for mirrored targets or highly available
configurations that provide paths to target data through
"storage servers". This would provide a basis for
technologies like high availability and clustering
The iSCSI protocol SHOULD also provide a method for sessions to
gracefully terminated and restarted that can be initiated by
the initiator or target. This provides the ability to
fail over an initiator or target, or reset a target after
maintenance tasks such as upgrading software
6.
It must be possible for initiators and targets that implement
required portions of the iSCSI specification to interoperate.
this requirement is so obvious that it doesn't seem worth mentioning
if the protocol specification contains ambiguous wording,
implementations may not interoperate. The iSCSI protocol
MUST be clear and unambiguous
6.1. Internet
The iSCSI protocol MUST
-- be compatible with both IPv4 and IPv6.
-- use TCP connections conservatively, keeping in mind there
be many other users of TCP on a given machine
The iSCSI protocol MUST NOT require changes to existing
protocols and SHOULD minimize required changes to existing TCP/
implementations
iSCSI MUST be designed to allow future substitution of SCTP (for TCP
as an IP transport protocol with minimal changes to iSCSI
operation, protocol data unit (PDU) structures and formats.
not widely implemented today, SCTP has many design features that
it a desirable choice for future iSCSI enhancement
6.2.
In order to be considered a SCSI transport, the iSCSI standard
comply with the requirements of the SCSI Architecture Model [SAM-2]
for a SCSI transport. Any feature SAM2 requires in a valid
mapping MUST be specified by iSCSI. The iSCSI protocol document
Krueger, et al. Informational [Page 16]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
specify for each feature whether it is OPTIONAL, RECOMMENDED
REQUIRED to implement and/or use
The SCSI Architectural Model [SAM-2] indicates an expectation
the SCSI transport provides ordering of commands on an
target-LUN granularity. There has been much discussion on the
reflector and in working group meetings regarding the means to
this ordering. The rough consensus is that iSCSI MUST
strictly ordered delivery of SCSI commands over an iSCSI
between an initiator/target pair, even in the presence of
errors. This command ordering mechanism SHOULD seek to minimize
amount of communication necessary across multiple adapters
transport off-load. If an iSCSI implementation does not
ordering it can instantiate multiple sessions per initiator-
pair
iSCSI is intended to be a new SCSI "transport" [SAM2]. As a
of SCSI over TCP, iSCSI requires interaction with both T10 and IETF
However, the iSCSI protocol MUST NOT require changes to the SCSI-3
command sets and SCSI client code except where SCSI
point to "transport dependent" fields and behavior. For example
changes to SCSI documents will be necessary to reflect
iSCSI target names and potentially lengthier timeouts.
with T10 will be necessary to achieve this requirement
The iSCSI protocol SHOULD track changes to SCSI and the
Architecture Model
The iSCSI protocol MUST be capable of supporting all SCSI-3
sets and device types. The primary focus is on supporting 'larger
devices: host computers and storage controllers (disk arrays,
libraries). However, other command sets (printers, scanners) must
supported. These requirements MUST NOT be construed to mean
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
stops execution of a sequence of dependent SCSI commands when one
them fails. The situation surrounding it is complex - T10
ACA in SAM2, and hence iSCSI must support it and endeavor to
sure that ACA gets implemented sufficiently (two
interoperable implementations) to avoid dropping ACA in
transition from Proposed Standard to Draft Standard. This
iSCSI SHOULD support ACA implementation
The iSCSI protocol MUST allow for the construction of gateways
other SCSI transports, including parallel SCSI [SPI-X] and to
FCP[FCP, FCP-2]. It MUST be possible to construct "translating
Krueger, et al. Informational [Page 17]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
gateways so that iSCSI hosts can interoperate with SCSI-X devices;
that SCSI-X devices can communicate over an iSCSI network; and
that SCSI-X hosts can use iSCSI targets (where SCSI-X refers
parallel SCSI, SCSI-FCP, or SCSI over any other transport).
requirement is implied by support for SAM-2, but is worthy
emphasis. These are true application protocol gateways, and not
bridge/routers. The different standards have only the SCSI-3
set layer in common. These gateways are not mere packet forwarders
The iSCSI protocol MUST reliably transport SCSI commands from
initiator to the target. According to [SAM-2, p. 17.] "The
of the service delivery subsystem is to transport an error-free
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
7. Security
In the past, directly attached storage systems have
minimal security checks because the physical connection
little chance for attack. Transporting block storage (SCSI) over
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).
7.1. Extensible
The security services required for communications depends on
individual network configurations and environments.
are setting up Virtual Private Networks(VPN), also known
Intranets, that will require one set of security functions
communications within the VPN and possibly many different
functions for communications outside the VPN to
geographically separate components. The iSCSI protocol is
to a wide range of internet working environments that may
different security policies. iSCSI MUST provide for
authentication when increased security is required. The
SHOULD require minimal configuration and overhead in the
operation, and allow integration of new security mechanisms
breaking backwards compatible operation
7.2.
The iSCSI protocol MAY support various levels of
security, ranging from no authentication to secure
using public or private keys
The iSCSI protocol MUST support private authenticated login
Krueger, et al. Informational [Page 18]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
Authenticated login aids the target in blocking the unauthorized
of SCSI resources. "Private" authenticated login mandates
identity exchange (no clear text passwords at a minimum).
block storage confidentiality is considered critical in
and many IP networks may have access holes, organizations will
to protect their iSCSI resources
The iSCSI authenticated login MUST be resilient against attacks
many IP networks are vulnerable to packet inspection
In addition, the iSCSI protocol MUST support data
authentication of its communications; data origin authentication
be optional to use. Data origin authentication is critical since
networks are vulnerable to source spoofing, where a malicious
party pretends to send packets from the initiator's IP address.
requirements should be met using standard Internet protocols such
IPsec or TLS. The endpoints may negotiate the authentication method
optionally none
7.3. Data
The iSCSI protocol SHOULD NOT preclude use of additional
integrity protection protocols (IPSec, TLS).
7.4. Data
Block storage is used for storing sensitive information, where
confidentiality is critical. An application may encrypt the
blocks before writing them to storage - this provides the
protection for the application. Even if the storage
communications are compromised, the attacker will have
reading the data
In certain environments, encryption may be desired to provide
extra assurance of confidentiality. An iSCSI implementation
provide for the use of a data encryption protocol such as TLS
IPsec ESP to provide data confidentiality between iSCSI endpoints
8.
iSCSI implementations SHOULD be manageable using standard IP-
management protocols. However, the iSCSI protocol document MUST
define the management architecture for iSCSI within the
infrastructure. iSCSI will be yet another resource service within
complex environment of network resources (printers, file servers
NAS, application servers, etc). There will certainly be efforts
design how the "block storage service" that iSCSI devices provide
integrated into a comprehensive, shared model, network
Krueger, et al. Informational [Page 19]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
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
presumably will want to interact with these integrated
management applications. The iSCSI protocol document will
attempt to solve that set of problems, or specify means for
to provide management agents. In fact, there should be no mention
MIBs or any other means of managing iSCSI devices as
references in the iSCSI protocol document, because management
and protocols change with the needs of the environment and
business models of the management applications
8.1.
Whenever possible, iSCSI MUST support the naming architecture
SAM-2. Deviations and uncertainties MUST be made explicit,
comments and resolutions worked out between ANSI T10 and the
working group
The means by which an iSCSI resource is located MUST use or
existing Internet standard resource location methods. RFC 2348 [12]
specifies URL syntax and semantics which should be
extensible for the iSCSI resource
The iSCSI protocol MUST provide a means of identifying an
storage device by a unique identifier that is independent of the
on which it is found. This name will be used to correlate
paths to the same device. The format for the iSCSI names MUST
existing naming authorities, to avoid creating new
administrative tasks. An iSCSI name SHOULD be a human
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
<hostname> portion of a URL to one or multiple IP addresses. When
hostname resolves to multiple addresses, these addresses should
equivalent for functional (possibly not performance) purposes.
means that the addresses can be used interchangeably as long
performance isn't a concern. For example, the same set of
targets MUST be accessible from each of these addresses
An iSCSI device naming scheme MUST interact correctly with
proposed SCSI security architecture [99-245r9]. Particular
must be directed to the proxy naming architecture defined by the
security model. In this new model, a host is identified by
Access ID, and SCSI Logical Unit Numbers (LUNs) can be mapped in
manner that gives each AccessID a unique LU map. Thus, a given
within a target may be addressed by different LUNs
Krueger, et al. Informational [Page 20]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
The iSCSI naming architecture MUST address support of SCSI 3rd
operations such as EXTENDED COPY. The key issue here relates to
naming architecture for SCSI LUs - iSCSI must provide a means
passing a name or handle between parties. iSCSI must specify a
of providing a name or handle that could be used in the XCOPY
and fit within the available space allocated by that command. And
must be possible, of course, for the XCOPY target (the third party
to de-reference the name to the correct target and LU
8.2.
iSCSI MUST have no impact on the use of current IP network
techniques. Network management platforms discover IP addresses
have various methods of probing the services available through
IP addresses. An iSCSI service should be evident using
techniques
The iSCSI specifications MUST provide some means of
whether an iSCSI service is available through an IP address. It
expected that iSCSI will be a point of service in a host, just
SNMP, etc are points of services, associated with a well known
number
SCSI protocol-dependent techniques SHOULD be used for
discovery beyond the iSCSI layer. Discovery is a complex, multi
layered process. The SCSI protocol specifications provide
commands for discovering LUs and the commands associated with
process will also work over iSCSI
The iSCSI protocol MUST provide a method of discovering, given an
end point on its well-known port, the list of SCSI targets
to the requestor. The use of this discovery service MUST
optional
Further discovery guidelines are outside the scope of this
and may be addressed in separate Informational documents
9. Internet
9.1. Denial of
As with all services, the denial of service by either
implementations or malicious agents is always a concern. All
of the iSCSI protocol SHOULD be scrutinized for potential denial
service issues, and guarded against as much as possible
Krueger, et al. Informational [Page 21]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
9.2. NATs, Firewalls and Proxy
NATs (Network Address Translator), firewalls, and proxy servers are
reality in today's Internet. These devices present a number
challenges to device access methods being developed for iSCSI.
example, specifying a URL syntax for iSCSI resource connection
an initiator to address an iSCSI target device both directly
through an iSCSI proxy server or NAT. iSCSI SHOULD allow
where functional and optimizing middle-boxes such as firewalls,
servers and NATs are present
The iSCSI protocol's use of IP addressing and TCP port numbers
be firewall friendly. This means that all connection requests
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
would require different source port numbers (for uniqueness),
could be opened after a security dialogue on the control channel
It's important that iSCSI operate through a firewall to provide
possible means of defending against Denial of Service (DoS)
from less-trusted areas of the network. It is assumed that
firewall will have much greater processing power for dismissing
connection requests than end nodes
9.3. Congestion Control and Transport
The iSCSI protocol MUST be a good network citizen with
congestion control (as defined in [RFC2914]). In addition,
implementations MUST NOT use multiple connections as a means to
transport-layer congestion control
10.
Certain definitions are offered here, with references to the
document where applicable, in order to clarify the discussion
requirements. Definitions without references are the work of
authors and reviewers of this document
Logical Unit (LU): A target-resident entity that implements a
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
[SAM-2, sec. 3.1.52, p. 7].
Krueger, et al. Informational [Page 22]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
SCSI Device: A device that is connected to a service
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
application client, device server, or task manager to enter
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
one or more logical units for execution [SAM-2 sec. 3.1.97, p. 10].
Task: An object within the logical unit representing the
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,
the exchange of information or the execution of some service by
object on behalf of the other [SAM-2, sec. 3.1.109, p. 10].
11.
1. Bradner, S., "The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996.
2. Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
3. [SAM-2] ANSI NCITS. Weber, Ralph O., editor. SCSI
Model -2 (SAM-2). T10 Project 1157-D. rev 23, 16 Mar 2002.
4. [SPC-2] ANSI NCITS. Weber, Ralph O., editor. SCSI
Commands 2 (SPC-2). T10 Project 1236-D. rev 20, 18
2001.
5. [CAM-3] ANSI NCITS. Dallas, William D., editor.
Technology - Common Access Method - 3 (CAM-3)). X3T10
990D. rev 3, 16 Mar 1998.
6. [99-245r8] Hafner, Jim. A Detailed Proposal for
Controls. T10/99-245 revision 9, 26 Apr 2000.
7. [SPI-X] ANSI NCITS. SCSI Parallel Interface - X
8. [FCP] ANSI NCITS. SCSI-3 Fibre Channel Protocol [
X3.269:1996].
Krueger, et al. Informational [Page 23]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
9. [FCP-2] ANSI NCITS. SCSI-3 Fibre Channel Protocol - 2
[T10/1144-D].
10. Paxon, V. End-to-end internet packet dynamics, IEEE
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. Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC 2348,
1998.
13. Floyd, S., "Congestion Control Principles", BCP 14, RFC 2914,
September 2000.
12.
Special thanks to Julian Satran, IBM and David Black, EMC for
extensive review comments
Krueger, et al. Informational [Page 24]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
13. Author's
Address comments to
Marjorie
Hewlett-Packard
8000 Foothills
Roseville, CA 95747-5668,
Phone: +1 916 785-2656
EMail: marjorie_krueger@hp.
Randy
Hewlett-Packard
8000 Foothills
Roseville, CA 95747-5668,
Phone: +1 916 785-4578
EMail: Randy_Haagens@hp.
Costa
Stanford
353 Serra Mall Dr #407
Stanford, CA 94305
Phone: 650-723-2458
EMail: csapuntz@stanford.
Mark
Cisco Systems, Inc
6450 Wedgwood
Maple Grove, MN 55311
Phone: +1 763 398-1054
EMail: mbakke@cisco.
Krueger, et al. Informational [Page 25]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
14. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Krueger, et al. Informational [Page 26]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
