rfc3347.txt

一个学习iSCSI协议的文档

   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: [phone]
   EMail: [e-mail]

   Randy Haagens
   Hewlett-Packard Corporation
   8000 Foothills Blvd
   Roseville, CA 95747-5668, USA
   Phone: [phone]
   EMail: [e-mail]

   Costa Sapuntzakis
   Stanford University
   353 Serra Mall Dr #407
   Stanford, CA 94305
   Phone: [phone]
   EMail: [e-mail]

   Mark Bakke
   Cisco Systems, Inc.
   6450 Wedgwood Road
   Maple Grove, MN 55311
   Phone: [phone]
   EMail: [e-mail]




















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]