summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3347.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3347.txt')
-rw-r--r--doc/rfc/rfc3347.txt1459
1 files changed, 1459 insertions, 0 deletions
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 <network round trip> 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
+ <hostname> 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]
+