< draft-ietf-ips-iscsi-reqmts-04.txt   draft-ietf-ips-iscsi-reqmts-05.txt >
IP Storage Working Group M. Krueger IP Storage Working Group M. Krueger
R. Haagens R. Haagens
Internet Draft Hewlett-Packard Internet Draft Hewlett-Packard
Category: Informational Corporation Corporation
Category: Informational
C. Sapuntzakis C. Sapuntzakis
M. Bakke M. Bakke
Cisco Systems Cisco Systems
Document: draft-ietf-ips-iscsi-reqmts-04.txt June 2001 Document: draft-ietf-ips-iscsi-reqmts-05.txt July 2001
iSCSI Requirements and Design Considerations iSCSI Requirements and Design Considerations
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 67 skipping to change at line 67
thought is that using these mature protocols will entail a minimum thought is that using these mature protocols will entail a minimum
of new invention, the most rapid possible adoption, and the greatest of new invention, the most rapid possible adoption, and the greatest
compatibility with Internet architecture, protocols, and equipment. compatibility with Internet architecture, protocols, and equipment.
The iSCSI protocol is a mapping of SCSI to TCP, and constitutes a 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 "SCSI transport" as defined by the ANSI T10 document SCSI SAM-2
document [SAM2, p. 3, "Transport Protocols"]. document [SAM2, p. 3, "Transport Protocols"].
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document describes the requirements for a protocol design,
but does not define a protocol standard. Nevertheless, the
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2]. this document are to be interpreted as described in RFC-2119 [2].
Table of Contents Table of Contents
1. Summary of Requirements.............................................3 1. Summary of Requirements...........................................3
2. iSCSI Design Considerations.........................................7 2. iSCSI Design Considerations.......................................7
2.1. General Discussion................................................7 2.1. General Discussion..............................................7
2.2. Performance/Cost..................................................8 2.2. Performance/Cost................................................8
2.3. Framing..........................................................10 2.3. Framing.........................................................10
2.4. High bandwidth, bandwidth aggregation............................11 2.4. High bandwidth, bandwidth aggregation...........................11
3. Ease of implementation/complexity of protocol......................13 3. Ease of implementation/complexity of protocol.....................13
4. Reliability and Availability.......................................13 4. Reliability and Availability......................................13
4.1. Detection of Data Corruption.....................................13 4.1. Detection of Data Corruption....................................14
4.2. Recovery.........................................................14 4.2. Recovery........................................................14
5. Interoperability...................................................15 5. Interoperability..................................................15
5.1. Internet infrastructure..........................................15 5.1. Internet infrastructure.........................................15
5.2. SCSI.............................................................15 5.2. SCSI............................................................15
6. Security Considerations............................................16 6. Security Considerations...........................................16
6.1. Extensible Security..............................................17 6.1. Extensible Security.............................................17
6.2. Authentication...................................................17 6.2. Authentication..................................................17
6.3. Data Integrity...................................................18 6.3. Data Integrity..................................................18
6.4. Data Privacy.....................................................18 6.4. Data Confidentiality............................................18
7. Management.........................................................18 7. Management........................................................18
7.1. Naming...........................................................18 7.1. Naming..........................................................18
7.2. Discovery........................................................19 7.2. Discovery.......................................................19
8. Internet Accessibility.............................................20 8. Internet Accessibility............................................20
8.1. Denial of Service................................................20 8.1. Denial of Service...............................................20
8.2. Firewalls and Proxy servers......................................20 8.2. Firewalls and Proxy servers.....................................20
8.3. Congestion Control and Transport Selection.......................21 8.3. Congestion Control and Transport Selection......................21
9. Definitions........................................................21 9. Definitions.......................................................21
10. References.......................................................22 10. References........................................................21
11. Acknowledgements.................................................22 11. Acknowledgements..................................................22
12. Author's Addresses...............................................22 12. Author's Addresses................................................22
iSCSI Reqmnts and Design Considerations Nov. 2000 iSCSI Reqmnts and Design Considerations Nov. 2000
1. Summary of Requirements 1. Summary of Requirements
The iSCSI standard: The iSCSI standard:
>From section 2.2 Performance/Cost: >From section 2.2 Performance/Cost:
MUST allow implementations to equal or improve on the current state MUST allow implementations to equal or improve on the current state
of the art for SCSI interconnects. of the art for SCSI interconnects.
skipping to change at line 134 skipping to change at line 136
SHOULD permit direct data placement architectures. SHOULD permit direct data placement architectures.
MUST NOT impose complex operations on host software. MUST NOT impose complex operations on host software.
MUST provide for full utilization of available link bandwidth. MUST provide for full utilization of available link bandwidth.
MUST allow an implementation to exploit parallelism (multiple MUST allow an implementation to exploit parallelism (multiple
connections) at the device interfaces and within the interconnect connections) at the device interfaces and within the interconnect
fabric. fabric.
>From section 2.4 High Bandwidth/Bandwidth Agreggation: >From section 2.4 High Bandwidth/Bandwidth Aggregation:
MUST operate over a single TCP connection. MUST operate over a single TCP connection.
SHOULD support 'connection binding', and it MUST be optional to SHOULD support 'connection binding', and it MUST be optional to
implement. implement.
>From section 3 Ease of Implementation/Complexity of Protocol: >From section 3 Ease of Implementation/Complexity of Protocol:
SHOULD keep the protocol simple. SHOULD keep the protocol simple.
SHOULD minimize optional features. SHOULD minimize optional features.
skipping to change at line 239 skipping to change at line 241
SHOULD allow integration of new security mechanisms without breaking SHOULD allow integration of new security mechanisms without breaking
backwards compatible operation. backwards compatible operation.
>From section 6.2 Authentication: >From section 6.2 Authentication:
MAY support various levels of authentication security. MAY support various levels of authentication security.
MUST support private authenticated login. MUST support private authenticated login.
iSCSI authenticated login MUST be resilient against passive attacks. iSCSI authenticated login MUST be resilient against passive attacks.
MUST NOT preclude optional data origin authentication of its MUST support data origin authentication of its communications; data
communications. origin authentication MAY be optional to use.
>From section 6.3 Data Integrity: >From section 6.3 Data Integrity:
SHOULD NOT preclude use of additional data integrity protection SHOULD NOT preclude use of additional data integrity protection
protocols (IPSec, TLS). protocols (IPSec, TLS).
>From section 6.4 Data Privacy: >From section 6.4 Data Confidentiality:
MAY use a data encryption protocol such as TLS or IPsec ESP to MAY use a data encryption protocol such as TLS or IPsec ESP to
provide data privacy between iSCSI endpoints. provide data confidentiality between iSCSI endpoints.
>From section 7 Management: >From section 7 Management:
SHOULD be manageable using standard IP-based management protocols SHOULD be manageable using standard IP-based management protocols
(eg. SNMP, RMI, etc). (eg. SNMP, RMI, etc).
iSCSI protocol document MUST NOT define the management iSCSI protocol document MUST NOT define the management architecture
architecture for iSCSI, or make explicit references to management for iSCSI, or make explicit references to management objects such as
objects such as MIB variables. MIB variables.
>From section 7.1 Naming: >From section 7.1 Naming:
MUST support the naming architecture of SAM-2. MUST support the naming architecture of SAM-2.
iSCSI Reqmnts and Design Considerations Nov. 2000 iSCSI Reqmnts and Design Considerations Nov. 2000
The means by which an iSCSI resource is located MUST use or extend The means by which an iSCSI resource is located MUST use or extend
existing Internet standard resource location methods. existing Internet standard resource location methods.
MUST provide a means of identifying iSCSI targets by a unique MUST provide a means of identifying iSCSI targets by a unique
skipping to change at line 530 skipping to change at line 532
(2) WAN environment- the emergence of high bandwidth, high latency, (2) WAN environment- the emergence of high bandwidth, high latency,
low bit error rate physical media places huge buffer low bit error rate physical media places huge buffer
requirements on the physical interface solutions. requirements on the physical interface solutions.
iSCSI Reqmnts and Design Considerations Nov. 2000 iSCSI Reqmnts and Design Considerations Nov. 2000
First, vendors are producing network processing hardware that First, vendors are producing network processing hardware that
offloads network protocols to hardware solutions to achieve higher offloads network protocols to hardware solutions to achieve higher
data rates. The concept of "zero-copy" seeks to store blocks of data rates. The concept of "zero-copy" seeks to store blocks of
data in appropriate memory locations (aligned) directly off the data in appropriate memory locations (aligned) directly off the
wire, even in when data is reordered due to packet loss. This is wire, even when data is reordered due to packet loss. This is
necessary to drive actual data rates of 10 Gigabits and beyond. necessary to drive actual data rates of 10 Gigabit/sec and beyond.
Secondly, in order for iSCSI to be successful in the WAN arena it Secondly, in order for iSCSI to be successful in the WAN arena it
must be possible to operate efficiently in high bandwidth, high must be possible to operate efficiently in high bandwidth, high
delay networks. The emergence of multi-gigabit IP networks with delay networks. The emergence of multi-gigabit IP networks with
latencies in the tens to hundreds of milliseconds presents a latencies in the tens to hundreds of milliseconds presents a
challenge. To fill such large pipes, tens of megabytes of challenge. To fill such large pipes, it is necessary to have tens of
outstanding requests from the application are needed. In addition, megabytes of outstanding requests from the application. In addition,
some protocols potentially require tens of megabytes at the some protocols potentially require tens of megabytes at the
transport layer to deal with buffering for reassembly of data when transport layer to deal with buffering for reassembly of data when
packets are received out-of-order. packets are received out-of-order.
In both cases, the issue is the desire to minimize the amount of
memory and memory bandwidth required for iSCSI hardware solutions.
Consider that a network pipe at 10 Gbps x 200 msec holds 250 MB. 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 [Assume land-based communication with a spot half way around the
world at the equator. Ignore additional distance due to cable world at the equator. Ignore additional distance due to cable
routing. Ignore repeater and switching delays; consider only a routing. Ignore repeater and switching delays; consider only a
speed-of-light delay of 5 microsec/km. The circumference of the speed-of-light delay of 5 microsec/km. The circumference of the
globe at the equator is approx. 40000 km (round-trip delay must be globe at the equator is approx. 40000 km (round-trip delay must be
considered to keep the pipe full). 10 Gb/sec x 40000 km x 5 considered to keep the pipe full). 10 Gb/sec x 40000 km x 5
microsec/km x B / 8b = 250 MB]. In a conventional TCP microsec/km x B / 8b = 250 MB]. In a conventional TCP
implementation, loss of a TCP segment means that stream processing implementation, loss of a TCP segment means that stream processing
MUST stop until that segment is recovered, which takes at least a MUST stop until that segment is recovered, which takes at least a
skipping to change at line 565 skipping to change at line 570
into an anonymous buffer before resuming stream processing; later, into an anonymous buffer before resuming stream processing; later,
this data would need to be moved to its proper location. Some this data would need to be moved to its proper location. Some
proponents of iSCSI seek some means of putting data directly where proponents of iSCSI seek some means of putting data directly where
it belongs, and avoiding extra data movement in the case of segment it belongs, and avoiding extra data movement in the case of segment
drop. This is a key concept in understanding the debate behind drop. This is a key concept in understanding the debate behind
framing methodologies. framing methodologies.
The framing of the iSCSI protocol impacts both the "interfacing The framing of the iSCSI protocol impacts both the "interfacing
needs" and the "accelerated processing needs", however, while needs" and the "accelerated processing needs", however, while
including a length in a header may suffice for the "interfacing including a length in a header may suffice for the "interfacing
needs", it will not serve the "accelerated processing needs". The needs", it will not serve the direct data placement needs. The
framing mechanism developed should allow resynchronization of packet framing mechanism developed should allow resynchronization of packet
boundaries even in the case where a packet is temporarily missing in boundaries even in the case where a packet is temporarily missing in
the incoming data stream. the incoming data stream.
2.4. High bandwidth, bandwidth aggregation 2.4. High bandwidth, bandwidth aggregation
At today's block storage transport throughput, any single link can At today's block storage transport throughput, any single link can
be saturated by the volume of storage traffic. Scientific data be saturated by the volume of storage traffic. Scientific data
applications, asynchronous and synchronous data replication are
examples of storage applications that push the limits of throughput.
iSCSI Reqmnts and Design Considerations Nov. 2000 iSCSI Reqmnts and Design Considerations Nov. 2000
applications and data replication are examples of storage
applications that push the limits of throughput.
Some applications, such as log updates, streaming tape, and Some applications, such as log updates, streaming tape, and
replication, require ordering of updates and thus ordering of SCSI replication, require ordering of updates and thus ordering of SCSI
commands. An initiator may maintain ordering by waiting for each commands. An initiator may maintain ordering by waiting for each
update to complete before issuing the next (a.k.a. synchronous update to complete before issuing the next (a.k.a. synchronous
updates). However, the throughput of synchronous updates decreases updates). However, the throughput of synchronous updates decreases
inversely with increases in latency of the operation. inversely with increases in network distances.
For greater throughput, the SCSI task queuing mechanism allows an For greater throughput, the SCSI task queuing mechanism allows an
initiator to have multiple commands outstanding at the target initiator to have multiple commands outstanding at the target
simultaneously and to express ordering constraints on the execution simultaneously and to express ordering constraints on the execution
of those commands. The task queuing mechanism is only effective if of those commands. The task queuing mechanism is only effective if
the commands arrive at the target in the order they were presented the commands arrive at the target in the order they were presented
to the initiator (FIFO order). The iSCSI standard must provide an to the initiator (FIFO order). The iSCSI standard must provide an
ordered transport of SCSI commands, even when commands are sent ordered transport of SCSI commands, even when commands are sent
along different network paths (see Section 5.2 SCSI). This is along different network paths (see Section 5.2 SCSI). This is
referred to as "command ordering". referred to as "command ordering".
skipping to change at line 678 skipping to change at line 683
simple as possible. simple as possible.
In the interest of simplicity, iSCSI SHOULD minimize optional In the interest of simplicity, iSCSI SHOULD minimize optional
features. When features are deemed necessary, the protocol MUST features. When features are deemed necessary, the protocol MUST
specify feature negotiation at session establishment (login). The specify feature negotiation at session establishment (login). The
iSCSI transport MUST operate correctly when no optional features are iSCSI transport MUST operate correctly when no optional features are
negotiated as well as when individual option negotions are negotiated as well as when individual option negotions are
unsuccessful. unsuccessful.
4. Reliability and Availability 4. Reliability and Availability
iSCSI Reqmnts and Design Considerations Nov. 2000
4.1. Detection of Data Corruption 4.1. Detection of Data Corruption
iSCSI Reqmnts and Design Considerations Nov. 2000
There have been several research papers that suggest that the TCP There have been several research papers that suggest that the TCP
checksum calculation allows a certain number of bit errors to pass checksum calculation allows a certain number of bit errors to pass
undetected [10] [11]. undetected [10] [11].
In order to protect against data corruption, the iSCSI protocol MUST In order to protect against data corruption, the iSCSI protocol MUST
support a data integrity check format for use in digest generation. support a data integrity check format for use in digest generation.
The iSCSI protocol MAY use separate digests for data and headers. In The iSCSI protocol MAY use separate digests for data and headers. In
an iSCSI proxy or gateway situation, the iSCSI headers are removed an iSCSI proxy or gateway situation, the iSCSI headers are removed
skipping to change at line 731 skipping to change at line 736
The iSCSI protocol error recover mechanism SHOULD take into account The iSCSI protocol error recover mechanism SHOULD take into account
fail-over schemes for mirrored targets or highly available storage fail-over schemes for mirrored targets or highly available storage
configurations that provide paths to target data through multiple configurations that provide paths to target data through multiple
"storage servers". This would provide a basis for layered "storage servers". This would provide a basis for layered
technologies like high availability and clustering. technologies like high availability and clustering.
The iSCSI protocol SHOULD also provide a method for sessions to be The iSCSI protocol SHOULD also provide a method for sessions to be
gracefully terminated and restarted that can be initiated by either gracefully terminated and restarted that can be initiated by either
the initiator or target. This provides the ability to gracefully the initiator or target. This provides the ability to gracefully
iSCSI Reqmnts and Design Considerations Nov. 2000
fail over an initiator or target, or reset a target after performing fail over an initiator or target, or reset a target after performing
maintenance tasks such as upgrading software. maintenance tasks such as upgrading software.
iSCSI Reqmnts and Design Considerations Nov. 2000
5. Interoperability 5. Interoperability
It must be possible for initiators and targets that implement the It must be possible for initiators and targets that implement the
required portions of the iSCSI specification to interoperate. While required portions of the iSCSI specification to interoperate. While
this requirement is so obvious that it doesn't seem worth this requirement is so obvious that it doesn't seem worth
mentioning, if the protocol specification contains ambiguous mentioning, if the protocol specification contains ambiguous
wording, different implementations may not interoperate. The iSCSI wording, different implementations may not interoperate. The iSCSI
protocol document MUST be clear and unambiguous. protocol document MUST be clear and unambiguous.
5.1. Internet infrastructure 5.1. Internet infrastructure
skipping to change at line 781 skipping to change at line 786
session between an initiator/target pair, even in the presence of session between an initiator/target pair, even in the presence of
transport errors. This command ordering mechanism SHOULD seek to transport errors. This command ordering mechanism SHOULD seek to
minimize the amount of communication necessary across multiple minimize the amount of communication necessary across multiple
adapters doing transport off-load. If an iSCSI implementation does adapters doing transport off-load. If an iSCSI implementation does
not require ordering it can instantiate multiple sessions per not require ordering it can instantiate multiple sessions per
initiator-target pair. initiator-target pair.
iSCSI is intended to be a new SCSI "transport" [SAM2]. As a mapping iSCSI is intended to be a new SCSI "transport" [SAM2]. As a mapping
of SCSI over TCP, iSCSI requires interaction with both T10 and IETF. of SCSI over TCP, iSCSI requires interaction with both T10 and IETF.
However, the iSCSI protocol MUST NOT require changes to the SCSI-3 However, the iSCSI protocol MUST NOT require changes to the SCSI-3
command sets and SCSI client code except where SCSI specifications
point to "transport dependant" fields and behavior. For example,
iSCSI Reqmnts and Design Considerations Nov. 2000 iSCSI Reqmnts and Design Considerations Nov. 2000
command sets and SCSI client code except where SCSI specifications
point to "transport dependant" fields and behavior. For example,
changes to SCSI documents will be necessary to reflect lengthier changes to SCSI documents will be necessary to reflect lengthier
iSCSI target names and potentially lengthier timeouts. iSCSI target names and potentially lengthier timeouts.
Collaboration with T10 will be necessary to achieve this Collaboration with T10 will be necessary to achieve this
requirement. requirement.
The iSCSI protocol SHOULD track changes to SCSI and the SCSI The iSCSI protocol SHOULD track changes to SCSI and the SCSI
Architecture Model. Architecture Model.
The iSCSI protocol MUST be capable of supporting all SCSI-3 command The iSCSI protocol MUST be capable of supporting all SCSI-3 command
sets and device types. The primary focus is on supporting 'larger' sets and device types. The primary focus is on supporting 'larger'
skipping to change at line 808 skipping to change at line 813
iSCSI must be natively implementable on all of today's SCSI devices, iSCSI must be natively implementable on all of today's SCSI devices,
which might have limited processing power or memory. which might have limited processing power or memory.
ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that
stops execution of a sequence of dependent SCSI commands when one of stops execution of a sequence of dependent SCSI commands when one of
them fails. The situation surrounding it is complex - T10 specifies them fails. The situation surrounding it is complex - T10 specifies
ACA in SAM2, and hence iSCSI must support it and endeavor to make ACA in SAM2, and hence iSCSI must support it and endeavor to make
sure that ACA gets implemented sufficiently (two independent sure that ACA gets implemented sufficiently (two independent
interoperable implementations) to avoid dropping ACA in the interoperable implementations) to avoid dropping ACA in the
transition from Proposed Standard to Draft Standard. This implies transition from Proposed Standard to Draft Standard. This implies
iSCSI SHOULD support ACA implementation. There is considerable iSCSI SHOULD support ACA implementation.
discussion on the IPS mailing list archives as to whether or not ACA
is ever used by a SCSI application.
The iSCSI protocol MUST allow for the construction of gateways to The iSCSI protocol MUST allow for the construction of gateways to
other SCSI transports, including parallel SCSI [SPI-X] and to SCSI- other SCSI transports, including parallel SCSI [SPI-X] and to SCSI-
FCP[FCP, FCP-2]. It MUST be possible to construct "translating" FCP[FCP, FCP-2]. It MUST be possible to construct "translating"
gateways so that iSCSI hosts can interoperate with SCSI-X devices; gateways so that iSCSI hosts can interoperate with SCSI-X devices;
so that SCSI-X devices can communicate over an iSCSI network; and so so that SCSI-X devices can communicate over an iSCSI network; and so
that SCSI-X hosts can use iSCSI targets (where SCSI-X refers to that SCSI-X hosts can use iSCSI targets (where SCSI-X refers to
parallel SCSI, SCSI-FCP, or SCSI over any other transport). This parallel SCSI, SCSI-FCP, or SCSI over any other transport). This
requirement is implied by support for SAM-2, but is worthy of requirement is implied by support for SAM-2, but is worthy of
emphasis. These are true application protocol gateways, and not just emphasis. These are true application protocol gateways, and not just
skipping to change at line 869 skipping to change at line 872
6.2. Authentication 6.2. Authentication
The iSCSI protocol MAY support various levels of authentication The iSCSI protocol MAY support various levels of authentication
security, ranging from no authentication to secure authentication security, ranging from no authentication to secure authentication
using public or private keys. using public or private keys.
The iSCSI protocol MUST support private authenticated login. The iSCSI protocol MUST support private authenticated login.
Authenticated login aids the target in blocking the unauthorized use Authenticated login aids the target in blocking the unauthorized use
of SCSI resources. "Private" authenticated login mandates protected of SCSI resources. "Private" authenticated login mandates protected
identity exchange (no clear text passwords at a minimum). Since identity exchange (no clear text passwords at a minimum). Since
block storage privacy is considered critical in enterprises and many block storage confidentiality is considered critical in enterprises
IP networks may have access holes, organizations will want to and many IP networks may have access holes, organizations will want
protect their iSCSI resources. to protect their iSCSI resources.
The iSCSI authenticated login MUST be resilient against passive The iSCSI authenticated login MUST be resilient against passive
attacks since many IP networks are vulnerable to packet inspection. 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 In addition, the iSCSI protocol MUST support data origin
origin authentication of its communications. Data origin authentication of its communications; data origin authentication MAY
authentication is critical since IP networks are vulnerable to be optional to use. Data origin authentication is critical since IP
source spoofing, where a malicious third party can pretend to send networks are vulnerable to source spoofing, where a malicious third
packets from the initiatorÆs IP address. party pretends to send packets from the initiator's IP address.
These requirements should be met using standard Internet protocols These requirements should be met using standard Internet protocols
such as IPsec or TLS. The endpoints may negotiate the authentication such as IPsec or TLS. The endpoints may negotiate the authentication
method, optionally none. method, optionally none.
iSCSI Reqmnts and Design Considerations Nov. 2000 iSCSI Reqmnts and Design Considerations Nov. 2000
6.3. Data Integrity 6.3. Data Integrity
The iSCSI protocol SHOULD NOT preclude use of additional data The iSCSI protocol SHOULD NOT preclude use of additional data
integrity protection protocols (IPSec, TLS). integrity protection protocols (IPSec, TLS).
6.4. Data Privacy 6.4. Data Confidentiality
Block storage is used for storing sensitive information, where data Block storage is used for storing sensitive information, where data
privacy is critical. An application may encrypt the data blocks confidentiality is critical. An application may encrypt the data
before writing them to storage - this provides the best protection blocks before writing them to storage - this provides the best
for the application. Even if the storage or communications are protection for the application. Even if the storage or
compromised, the attacker will have difficulty reading the data. communications are compromised, the attacker will have difficulty
reading the data.
In certain environments, encryption may be desired to provide an In certain environments, encryption may be desired to provide an
extra assurance of privacy. An iSCSI implementation MAY use a data extra assurance of confidentiality. An iSCSI implementation MAY use
encryption protocol such as TLS or IPsec ESP to provide data privacy a data encryption protocol such as TLS or IPsec ESP to provide data
between iSCSI endpoints. confidentiality between iSCSI endpoints.
7. Management 7. Management
iSCSI implementations SHOULD be manageable using standard IP-based iSCSI implementations SHOULD be manageable using standard IP-based
management protocols (eg. SNMP, RMI, etc). However, the iSCSI management protocols (eg. SNMP, RMI, etc). However, the iSCSI
protocol document MUST NOT define the management architecture for protocol document MUST NOT define the management architecture for
iSCSI within the network infrastructure. iSCSI will be yet another iSCSI within the network infrastructure. iSCSI will be yet another
resource service within a complex environment of network resources resource service within a complex environment of network resources
(printers, file servers, NAS, application servers, etc). There will (printers, file servers, NAS, application servers, etc). There will
certainly be efforts to design how the "block storage service" that certainly be efforts to design how the "block storage service" that
skipping to change at line 934 skipping to change at line 937
In fact, there should be no mention of MIBs or any other means of In fact, there should be no mention of MIBs or any other means of
managing iSCSI devices as explicit references in the iSCSI protocol managing iSCSI devices as explicit references in the iSCSI protocol
document, because management data and protocols change with the document, because management data and protocols change with the
needs of the environment and the business models of the management needs of the environment and the business models of the management
applications. applications.
7.1. Naming 7.1. Naming
Whenever possible, iSCSI MUST support the naming architecture of Whenever possible, iSCSI MUST support the naming architecture of
SAM-2. Deviations and uncertainties MUST be made explicit, and SAM-2. Deviations and uncertainties MUST be made explicit, and
iSCSI Reqmnts and Design Considerations Nov. 2000
comments and resolutions worked out between ANSI T10 and the IPS comments and resolutions worked out between ANSI T10 and the IPS
working group. working group.
iSCSI Reqmnts and Design Considerations Nov. 2000
The means by which an iSCSI resource is located MUST use or extend The means by which an iSCSI resource is located MUST use or extend
existing Internet standard resource location methods. RFC 1783 [12] existing Internet standard resource location methods. RFC 1783 [12]
specifies URL syntax and semantics which should be sufficiently specifies URL syntax and semantics which should be sufficiently
extensible for the iSCSI resource. extensible for the iSCSI resource.
The iSCSI protocol MUST provide a means of identifying an iSCSI The iSCSI protocol MUST provide a means of identifying an iSCSI
storage device by a unique identifier that is independent of the storage device by a unique identifier that is independent of the
path on which it is found. This name will be used to correlate path on which it is found. This name will be used to correlate
alternate paths to the same device. The format for the iSCSI names alternate paths to the same device. The format for the iSCSI names
MUST use existing naming authorities, to avoid creating new central MUST use existing naming authorities, to avoid creating new central
administrative tasks. An iSCSI name SHOULD be a human readable administrative tasks. An iSCSI name SHOULD be a human readable
string in an international character set encoding. string in an international character set encoding.
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. Standard Internet lookup services SHOULD be used to resolve names.
For example, Domain Name Services (DNS) MAY be used to resolve the For example, Domain Name Services (DNS) MAY be used to resolve the
<hostname> portion of a URL to one or multiple IP addresses. When a <hostname> portion of a URL to one or multiple IP addresses. When a
hostname resolves to multiple addresses, these addresses should be hostname resolves to multiple addresses, these addresses should be
equivalent for functional (possibly not performance) purposes. This equivalent for functional (possibly not performance) purposes. This
means that the addresses can be used interchangeably as long as means that the addresses can be used interchangeably as long as
performance isnÆt a concern. For example, the same set of SCSI performance isn't a concern. For example, the same set of SCSI
targets MUST be accessible from each of these addresses. targets MUST be accessible from each of these addresses.
An iSCSI device naming scheme MUST interact correctly with the An iSCSI device naming scheme MUST interact correctly with the
proposed SCSI security architecture [99-245r9]. Particular proposed SCSI security architecture [99-245r9]. Particular
attention must be directed to the proxy naming architecture defined attention must be directed to the proxy naming architecture defined
by the new security model. In this new model, a host is identified by the new security model. In this new model, a host is identified
by an Access ID, and SCSI Logical Unit Numbers (LUNs) can be mapped 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 in a manner that gives each AccessID a unique LU map. Thus, a given
LU within a target may be addressed by different LUNs. LU within a target may be addressed by different LUNs.
skipping to change at line 985 skipping to change at line 983
operations such as EXTENDED COPY. The key issue here relates to the operations such as EXTENDED COPY. The key issue here relates to the
naming architecture for SCSI LUs - iSCSI must provide a means of naming architecture for SCSI LUs - iSCSI must provide a means of
passing a name or handle between parties. iSCSI must specify a means passing a name or handle between parties. iSCSI must specify a means
of providing a name or handle that could be used in the XCOPY of providing a name or handle that could be used in the XCOPY
command and fit within the available space allocated by that command and fit within the available space allocated by that
command. And it must be possible, of course, for the XCOPY target command. And it must be possible, of course, for the XCOPY target
(the third party) to dereference the name to the correct target and (the third party) to dereference the name to the correct target and
LU. LU.
7.2. Discovery 7.2. Discovery
iSCSI Reqmnts and Design Considerations Nov. 2000
iSCSI MUST have no impact on the use of current IP network discovery iSCSI MUST have no impact on the use of current IP network discovery
techniques. Network management platforms discover IP addresses and techniques. Network management platforms discover IP addresses and
have various methods of probing the services available through these have various methods of probing the services available through these
IP addresses. An iSCSI service should be evident using similar IP addresses. An iSCSI service should be evident using similar
techniques. techniques.
The iSCSI specifications MUST provide some means of determining The iSCSI specifications MUST provide some means of determining
whether an iSCSI service is available through an IP address. It is whether an iSCSI service is available through an IP address. It is
iSCSI Reqmnts and Design Considerations Nov. 2000
expected that iSCSI will be a point of service in a host, just as 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 SNMP, etc are points of services, associated with a well known port
number. number.
SCSI protocol-dependent techniques SHOULD be used for further SCSI protocol-dependent techniques SHOULD be used for further
discovery beyond the iSCSI layer. Discovery is a complex, multi- discovery beyond the iSCSI layer. Discovery is a complex, multi-
layered process. The SCSI protocol specifications provide specific layered process. The SCSI protocol specifications provide specific
commands for discovering LUs and the commands associated with this commands for discovering LUs and the commands associated with this
process will also work over iSCSI. process will also work over iSCSI.
skipping to change at line 1034 skipping to change at line 1033
a reality in today's Internet. These devices present a number of a reality in today's Internet. These devices present a number of
challenges to device access methods being developed for iSCSI. For challenges to device access methods being developed for iSCSI. For
example, specifying a URL syntax for iSCSI resource connection example, specifying a URL syntax for iSCSI resource connection
allows an initiator to address an iSCSI target device both directly allows an initiator to address an iSCSI target device both directly
and through an iSCSI proxy server or NAT. iSCSI SHOULD allow and through an iSCSI proxy server or NAT. iSCSI SHOULD allow
deployment where functional and optimizing middle-boxes such as deployment where functional and optimizing middle-boxes such as
firewalls, proxy servers and NATs are present. firewalls, proxy servers and NATs are present.
The iSCSI protocols use of IP addressing and TCP port numbers MUST The iSCSI protocols use of IP addressing and TCP port numbers MUST
be firewall friendly. This means that all connection requests should be firewall friendly. This means that all connection requests should
iSCSI Reqmnts and Design Considerations Nov. 2000
normally be addressed to a specific, well-known TCP port. That way, normally be addressed to a specific, well-known TCP port. That way,
firewalls can filter based on source and destination IP addresses, firewalls can filter based on source and destination IP addresses,
and destination (target) port number. Additional TCP connections and destination (target) port number. Additional TCP connections
would require different source port numbers (for uniqueness), but would require different source port numbers (for uniqueness), but
could be opened after a security dialogue on the control channel. could be opened after a security dialogue on the control channel.
ItÆs important that iSCSI operate through a firewall to provide a It's important that iSCSI operate through a firewall to provide a
possible means of defending against Denial of Service (DoS) assaults possible means of defending against Denial of Service (DoS) assaults
iSCSI Reqmnts and Design Considerations Nov. 2000
from less-trusted areas of the network. It is assumed that a from less-trusted areas of the network. It is assumed that a
firewall will have much greater processing power for dismissing firewall will have much greater processing power for dismissing
bogus connection requests than end nodes. bogus connection requests than end nodes.
8.3. Congestion Control and Transport Selection 8.3. Congestion Control and Transport Selection
The iSCSI protocol MUST be a good network citizen with proven The iSCSI protocol MUST be a good network citizen with proven
congestion control (as defined in RFC 2309). In addition, iSCSI congestion control (as defined in RFC 2309). In addition, iSCSI
implementations MUST NOT use multiple connections as a means to implementations MUST NOT use multiple connections as a means to
avoid transport-layer congestion control. avoid transport-layer congestion control.
skipping to change at line 1085 skipping to change at line 1084
retrieve requests and responses from the service delivery subsystem. 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]. Synonymous with port (SAM-2 sec. 3.1.61) [SAM-2, sec. 3.1.89, p. 9].
Target: A SCSI device that receives a SCSI command and directs it to 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]. 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 Task: An object within the logical unit representing the work
associated with a command or a group of linked commands [SAM-2, sec. associated with a command or a group of linked commands [SAM-2, sec.
3.1.98, p. 10]. 3.1.98, p. 10].
iSCSI Reqmnts and Design Considerations Nov. 2000
Transaction: A cooperative interaction between two objects, Transaction: A cooperative interaction between two objects,
involving the exchange of information or the execution of some 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, service by one object on behalf of the other [SAM-2, sec. 3.1.109,
p. 10]. p. 10].
10. References 10. References
iSCSI Reqmnts and Design Considerations Nov. 2000
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
3 [SAM-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Architecture 3 [SAM-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Architecture
Model -2 (SAM-2). T10 Project 1157-D. rev 13, 22 Mar 2000. Model -2 (SAM-2). T10 Project 1157-D. rev 13, 22 Mar 2000.
4 [SPC-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Primary 4 [SPC-2] ANSI NCITS. Weber, Ralph O., editor. SCSI Primary
Commands 2 (SPC-2). T10 Project 1236-D. rev 18, 21 May 2000. Commands 2 (SPC-2). T10 Project 1236-D. rev 18, 21 May 2000.
5 [CAM-3] ANSI NCITS. Dallas, William D., editor. Information 5 [CAM-3] ANSI NCITS. Dallas, William D., editor. Information
skipping to change at line 1121 skipping to change at line 1119
D]. D].
10 Paxon, V. End-to-end internet packet dynamics, IEEE Transactions 10 Paxon, V. End-to-end internet packet dynamics, IEEE Transactions
on Networking 7,3 (June 1999) pg 277-292. on Networking 7,3 (June 1999) pg 277-292.
11 Stone J., Partridge, C. When the CRC and TCP checksum disagree, 11 Stone J., Partridge, C. When the CRC and TCP checksum disagree,
ACM Sigcomm (Sept. 2000). ACM Sigcomm (Sept. 2000).
12 [RFC1783] Berners-Lee, t., et.al.,"Uniform Resource Locators", RFC 12 [RFC1783] Berners-Lee, t., et.al.,"Uniform Resource Locators", RFC
1783, December 1994. 1783, December 1994.
11. Acknowledgements 11. Acknowledgements
Special thanks to David Black, EMC and Julian Satran, IBM for their Special thanks to Julian Satran, IBM and David Black, EMC for their
extensive review comments. extensive review comments.
12. Author's Addresses 12. Author's Addresses
Address comments to: Address comments to:
Marjorie Krueger Marjorie Krueger
Hewlett-Packard Corporation Hewlett-Packard Corporation
iSCSI Reqmnts and Design Considerations Nov. 2000
8000 Foothills Blvd 8000 Foothills Blvd
Roseville, CA 95747-5668, USA Roseville, CA 95747-5668, USA
Phone: +1 916 785-2656 Phone: +1 916 785-2656
Email: marjorie_krueger@hp.com Email: marjorie_krueger@hp.com
Randy Haagens Randy Haagens
Hewlett-Packard Corporation Hewlett-Packard Corporation
8000 Foothills Blvd 8000 Foothills Blvd
iSCSI Reqmnts and Design Considerations Nov. 2000
Roseville, CA 95747-5668, USA Roseville, CA 95747-5668, USA
Phone: +1 916 785-4578 Phone: +1 916 785-4578
Email: Randy_Haagens@hp.com Email: Randy_Haagens@hp.com
Costa Sapuntzakis Costa Sapuntzakis
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134, USA San Jose, CA 95134, USA
Phone: +1 408 525-5497 Phone: +1 408 525-5497
Email: csapuntz@cisco.com Email: csapuntz@cisco.com
 End of changes. 43 change blocks. 
92 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/