📄 rfc3347.txt
字号:
Network Working Group M. Krueger
Request for Comments: 3347 R. Haagens
Category: Informational Hewlett-Packard Corporation
C. Sapuntzakis
Stanford
M. Bakke
Cisco Systems
July 2002
Small Computer Systems Interface protocol over the Internet (iSCSI)
Requirements and Design Considerations
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies the requirements iSCSI and its related
infrastructure should satisfy and the design considerations guiding
the iSCSI protocol development efforts. In the interest of timely
adoption of the iSCSI protocol, the IPS group has chosen to focus the
first version of the protocol to work with the existing SCSI
architecture and commands, and the existing TCP/IP transport layer.
Both these protocols are widely-deployed and well-understood. The
thought is that using these mature protocols will entail a minimum of
new invention, the most rapid possible adoption, and the greatest
compatibility with Internet architecture, protocols, and equipment.
Conventions used in this document
This document describes the requirements for a protocol design, but
does not define a protocol standard. Nevertheless, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC-2119 [2].
Krueger, et al. Informational [Page 1]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
Table of Contents
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. Introduction
The IP Storage Working group is chartered with developing
comprehensive technology to transport block storage data over IP
protocols. This effort includes a protocol to transport the Small
Computer Systems Interface (SCSI) protocol over the Internet (iSCSI).
The initial version of the iSCSI protocol will define a mapping of
SCSI transport protocol over TCP/IP so that SCSI storage controllers
(principally disk and tape arrays and libraries) can be attached to
IP networks, notably Gigabit Ethernet (GbE) and 10 Gigabit Ethernet
(10 GbE).
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 a
"SCSI transport" as defined by the ANSI T10 document SCSI SAM-2
document [SAM2, p. 3, "Transport Protocols"].
2. Summary of Requirements
The iSCSI standard:
From section 3.2 Performance/Cost:
MUST allow implementations to equal or improve on the current
state of the art for SCSI interconnects.
MUST enable cost competitive implementations.
SHOULD minimize control overhead to enable low delay
communications.
MUST provide high bandwidth and bandwidth aggregation.
MUST have low host CPU utilizations, equal to or better than
current technology.
MUST be possible to build I/O adapters that handle the entire SCSI
task.
SHOULD permit direct data placement architectures.
MUST NOT impose complex operations on host software.
MUST provide for full utilization of available link bandwidth.
MUST allow an implementation to exploit parallelism (multiple
connections) at the device interfaces and within the interconnect
fabric.
From section 3.4 High Bandwidth/Bandwidth Aggregation:
MUST operate over a single TCP connection.
SHOULD support 'connection binding', and it MUST be optional to
implement.
From section 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 as
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 digest
generation.
MAY use separate digest for data and headers.
iSCSI header format SHOULD be extensible to include other data
integrity digest calculation methods.
From section 5.2 Recovery:
MUST specify mechanisms to recover in a timely fashion from
failures on the initiator, target, or connecting infrastructure.
MUST specify recovery methods for non-idempotent requests.
SHOULD take into account fail-over schemes for mirrored targets or
highly available storage configurations.
SHOULD provide a method for sessions to be gracefully terminated
and restarted that can be initiated by either the initiator or
target.
From section 6 Interoperability:
iSCSI protocol document MUST be clear and unambiguous.
From section 6.1 Internet Infrastructure:
MUST:
-- be compatible with both IPv4 and IPv6
-- use TCP connections conservatively, keeping in mind there may
be many other users of TCP on a given machine.
MUST NOT require changes to existing Internet protocols.
SHOULD minimize required changes to existing TCP/IP
implementations.
MUST be designed to allow future substitution of SCTP (for TCP) as
an IP transport protocol with minimal changes to iSCSI protocol
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 be
specified by iSCSI.
MUST specify strictly ordered delivery of SCSI commands over an
iSCSI session between an initiator/target pair.
The command ordering mechanism SHOULD seek to minimize the amount
of communication necessary across multiple adapters doing
transport off-load.
MUST specify for each feature whether it is OPTIONAL, RECOMMENDED
or REQUIRED to implement and/or use.
MUST NOT require changes to the SCSI-3 command sets and SCSI
client code except except where SCSI specifications point to
"transport 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 device
types.
SHOULD support ACA implementation.
MUST allow for the construction of gateways to other SCSI
transports
MUST reliably transport SCSI commands from the initiator to the
target.
MUST correctly deal with iSCSI packet drop, duplication,
corruption, stale packets, and re-ordering.
From section 7.1 Extensible Security:
SHOULD require minimal configuration and overhead in the insecure
operation.
MUST provide for strong authentication when increased security is
required.
SHOULD allow integration of new security mechanisms without
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 protection
protocols (IPSec, TLS).
From section 7.4 Data Confidentiality:
MUST provide for the use of a data encryption protocol such as TLS
or IPsec ESP to provide data confidentiality between iSCSI
endpoints
From section 8 Management:
SHOULD be manageable using standard IP-based management protocols.
iSCSI protocol document MUST NOT define the management
architecture for iSCSI, or make explicit references to management
objects such as MIB variables.
From section 8.1 Naming:
MUST support the naming architecture of SAM-2. The means by which
an iSCSI resource is located MUST use or extend existing Internet
standard resource location methods.
MUST provide a means of identifying iSCSI targets by a unique
identifier that is independent of the path on which it is found.
The format for the iSCSI names MUST use existing naming
authorities.
An iSCSI name SHOULD be a human readable string in an
international character set encoding.
Standard Internet lookup services SHOULD be used to resolve iSCSI
names.
Krueger, et al. Informational [Page 6]
RFC 3347 iSCSI Requirements and Design Considerations July 2002
SHOULD deal with the complications of the new SCSI security
architecture.
iSCSI naming architecture MUST address support of SCSI 3rd party
operations such as EXTENDED COPY.
From section 8.2 Discovery:
MUST have no impact on the use of current IP network discovery
techniques.
MUST provide some means of determining whether an iSCSI service is
available through an IP address.
SCSI protocol-dependent techniques SHOULD be used for further
discovery beyond the iSCSI layer.
MUST provide a method of discovering, given an IP end point on its
well-known port, the list of SCSI targets available to the
requestor. The use of this discovery service MUST be optional.
From section 9 Internet Accessability.
SHOULD be scrutinized for denial of service issues and they should
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -