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