rfc3347.txt

一个学习iSCSI协议的文档

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