home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / iscsiprj.zip / draft-ietf-ips-iscsi-reqmts-06.txt < prev    next >
Text File  |  2002-06-02  |  59KB  |  1,397 lines
  1.  
  2.  
  3. IP Storage Working Group                                    M. Krueger 
  4.                                                             R. Haagens 
  5. Internet Draft                                         Hewlett-Packard 
  6.                                                            Corporation 
  7. Category: Informational                                                
  8.                                                         C. Sapuntzakis 
  9.                                                               M. Bakke 
  10.                                                          Cisco Systems 
  11.                                                                        
  12. Document: draft-ietf-ips-iscsi-reqmts-06.txt                March 2002 
  13.  
  14.  
  15.               iSCSI Requirements and Design Considerations 
  16.  
  17.  
  18. Status of this Memo 
  19.  
  20.    This document is an Internet-Draft and is in full conformance with 
  21.    all provisions of Section 10 of RFC2026 [1].  
  22.     
  23.    Internet-Drafts are working documents of the Internet Engineering 
  24.    Task Force (IETF), its areas, and its working groups.  Note that 
  25.    other groups may also distribute working documents as Internet-
  26.    Drafts. 
  27.     
  28.    Internet-Drafts are draft documents valid for a maximum of six 
  29.    months and may be updated, replaced, or obsoleted by other documents 
  30.    at any time.  It is inappropriate to use Internet-Drafts as 
  31.    reference material or to cite them other than as "work in progress." 
  32.     
  33.    The list of current Internet-Drafts can be accessed at 
  34.    http://www.ietf.org/ietf/1id-abstracts.txt 
  35.     
  36.    The list of Internet-Draft Shadow Directories can be accessed at 
  37.    http://www.ietf.org/shadow.html. 
  38.     
  39.     
  40. Abstract 
  41.     
  42.    The IP Storage Working group is chartered with developing 
  43.    comprehensive technology to transport block storage data over IP 
  44.    protocols.  This effort includes a protocol to transport the Small 
  45.    Computer Systems Interface (SCSI) protocol over the Internet 
  46.    (iSCSI).  The initial version of the iSCSI protocol will define a 
  47.    mapping of SCSI transport protocol over TCP/IP so that SCSI storage 
  48.    controllers (principally disk and tape arrays and libraries) can be 
  49.    attached to IP networks, notably Gigabit Ethernet (GbE) and 10 
  50.    Gigabit Ethernet (10 GbE). 
  51.     
  52.    This document specifies the requirements iSCSI and it's related 
  53.    infrastructure should satisfy and the design considerations guiding 
  54.    the iSCSI protocol development efforts. In the interest of timely 
  55.    adoption of the iSCSI protocol, the IPS group has chosen to focus 
  56.  
  57.   
  58. Krueger          Informational √ Expires August 2001                1 
  59.  
  60.                iSCSI Reqmnts and Design Considerations     March 2002 
  61.  
  62.  
  63.    the first version of the protocol to work with the existing SCSI 
  64.    architecture and commands, and the existing TCP/IP transport layer.  
  65.    Both these protocols are widely-deployed and well-understood.  The 
  66.    thought is that using these mature protocols will entail a minimum 
  67.    of new invention, the most rapid possible adoption, and the greatest 
  68.    compatibility with Internet architecture, protocols, and equipment. 
  69.     
  70.    The iSCSI protocol is a mapping of SCSI to TCP, and constitutes a 
  71.    "SCSI transport" as defined by the ANSI T10 document SCSI SAM-2 
  72.    document [SAM2, p. 3, "Transport Protocols"]. 
  73.     
  74. Conventions used in this document 
  75.     
  76.    This document describes the requirements for a protocol design, but 
  77.    does define a protocol standard.  Nevertheless, the key words 
  78.    "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
  79.    "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document 
  80.    are to be interpreted as described in RFC-2119 [2]. 
  81.     
  82. Table of Contents 
  83.     
  84. 1.  Summary of Requirements...........................................3 
  85. 2.  iSCSI Design Considerations.......................................7 
  86.  2.1. General Discussion..............................................7 
  87.  2.2. Performance/Cost................................................8 
  88.  2.3. Framing........................................................10 
  89.  2.4. High bandwidth, bandwidth aggregation..........................11 
  90. 3.  Ease of implementation/complexity of protocol....................13 
  91. 4.  Reliability and Availability.....................................13 
  92.  4.1. Detection of Data Corruption...................................14 
  93.  4.2. Recovery.......................................................14 
  94. 5.  Interoperability.................................................15 
  95.  5.1. Internet infrastructure........................................15 
  96.  5.2. SCSI...........................................................15 
  97. 6.  Security Considerations..........................................17 
  98.  6.1. Extensible Security............................................17 
  99.  6.2. Authentication.................................................17 
  100.  6.3. Data Integrity.................................................18 
  101.  6.4. Data Confidentiality...........................................18 
  102. 7.  Management.......................................................18 
  103.  7.1. Naming.........................................................19 
  104.  7.2. Discovery......................................................19 
  105. 8.  Internet Accessibility...........................................20 
  106.  8.1. Denial of Service..............................................20 
  107.  8.2. NATs, Firewalls and Proxy servers..............................20 
  108.  8.3. Congestion Control and Transport Selection.....................21 
  109. 9.  Definitions......................................................21 
  110. 10.   References.....................................................22 
  111. 11.   Acknowledgements...............................................22 
  112. 12.   Author's Addresses.............................................22 
  113.    
  114.  
  115.  
  116.  
  117.   
  118. Krueger             Informational   Exp. Sept 2002                   2 
  119.  
  120.                iSCSI Reqmnts and Design Considerations     March 2002 
  121.  
  122.  
  123.    
  124.  
  125. 1. Summary of Requirements 
  126.     
  127.    The iSCSI standard: 
  128.     
  129. >From section 2.2 Performance/Cost: 
  130.    MUST allow implementations to equal or improve on the current state 
  131.    of the art for SCSI interconnects. 
  132.     
  133.    MUST enable cost competitive implementations. 
  134.  
  135.    SHOULD minimize control overhead to enable low delay communications. 
  136.     
  137.    MUST provide high bandwidth and bandwidth aggregation. 
  138.     
  139.    MUST have low host CPU utilizations, equal to or better than current 
  140.    technology. 
  141.     
  142.    MUST be possible to build I/O adapters that handle the entire SCSI 
  143.    task. 
  144.     
  145.    SHOULD permit direct data placement architectures. 
  146.     
  147.    MUST NOT impose complex operations on host software. 
  148.     
  149.    MUST provide for full utilization of available link bandwidth. 
  150.     
  151.    MUST allow an implementation to exploit parallelism (multiple 
  152.    connections) at the device interfaces and within the interconnect 
  153.    fabric. 
  154.     
  155. >From section 2.4 High Bandwidth/Bandwidth Aggregation: 
  156.    MUST operate over a single TCP connection.  
  157.     
  158.    SHOULD support 'connection binding', and it MUST be optional to 
  159.    implement. 
  160.     
  161.     
  162. >From section 3 Ease of Implementation/Complexity of Protocol: 
  163.    SHOULD keep the protocol simple. 
  164.     
  165.    SHOULD minimize optional features. 
  166.     
  167.    MUST specify feature negotiation at session establishment (login). 
  168.     
  169.    MUST operate correctly when no optional features are negotiated as 
  170.    well as when individual option negotions are unsuccessful. 
  171.     
  172. >From section 4.1 Detection of Data Corruption: 
  173.    MUST support a data integrity check format for use in digest 
  174.    generation. 
  175.   
  176. Krueger             Informational   Exp. Sept 2002                   3 
  177.  
  178.                iSCSI Reqmnts and Design Considerations     March 2002 
  179.  
  180.  
  181.      
  182.    MAY use separate digest for data and headers. 
  183.      
  184.    iSCSI header format SHOULD be extensible to include other data 
  185.    integrity digest calculation methods. 
  186.     
  187. >From section 4.2 Recovery: 
  188.    MUST specify mechanisms to recover in a timely fashion from  
  189.    failures on the initiator, target, or connecting infrastructure. 
  190.     
  191.    MUST specify recovery methods for non-idempotent requests. 
  192.     
  193.    SHOULD take into account fail-over schemes for mirrored targets or 
  194.    highly available storage configurations. 
  195.     
  196.    SHOULD provide a method for sessions to be gracefully terminated and 
  197.    restarted that can be initiated by either the initiator or target.   
  198.     
  199. >From section 5 Interoperability: 
  200.    iSCSI protocol document MUST be clear and unambiguous. 
  201.     
  202. >From section 5.1 Internet Infrastructure: 
  203.    MUST: 
  204.     -- be compatible with both IPv4 and IPv6 
  205.     -- use TCP connections conservatively, keeping in mind there may be 
  206.        many other users of TCP on a given machine. 
  207.      
  208.    MUST NOT require changes to existing Internet protocols. 
  209.     
  210.     SHOULD minimize required changes to existing TCP/IP 
  211.    implementations. 
  212.     
  213.    MUST be designed to allow future substitution of SCTP (for TCP) as 
  214.    an IP transport protocol with minimal changes to iSCSI protocol 
  215.    operation, protocol data unit (PDU) structures and formats.  
  216.     
  217. >From section 5.2 SCSI: 
  218.    Any feature SAM2 requires in a valid transport mapping MUST be 
  219.    specified by iSCSI. 
  220.     
  221.    MUST specify strictly ordered delivery of SCSI commands over an 
  222.    iSCSI session between an initiator/target pair. 
  223.     
  224.    The command ordering mechanism SHOULD seek to minimize the amount of 
  225.    communication necessary across multiple adapters doing transport 
  226.    off-load. 
  227.     
  228.    MUST specify for each feature whether it is OPTIONAL, RECOMMENDED or 
  229.    REQUIRED to implement and/or use. 
  230.     
  231.    MUST NOT require changes to the SCSI-3 command sets and SCSI client 
  232.    code except except where SCSI specifications point to "transport 
  233.    dependant" fields and behavior. 
  234.   
  235. Krueger             Informational   Exp. Sept 2002                   4 
  236.  
  237.                iSCSI Reqmnts and Design Considerations     March 2002 
  238.  
  239.  
  240.     
  241.    SHOULD track changes to SCSI and the SCSI Architecture Model. 
  242.     
  243.    MUST be capable of supporting all SCSI-3 command sets and device 
  244.    types. 
  245.     
  246.    SHOULD support ACA implementation. 
  247.     
  248.    MUST allow for the construction of gateways to other SCSI transports 
  249.     
  250.    MUST reliably transport SCSI commands from the initiator to the 
  251.    target.   
  252.     
  253.    MUST correctly deal with iSCSI packet drop, duplication, corruption, 
  254.    stale packets, and re-ordering. 
  255.     
  256. >From section 6.1 Extensible Security: 
  257.    SHOULD require minimal configuration and overhead in the insecure 
  258.    operation. 
  259.     
  260.    MUST provide for strong authentication when increased security is 
  261.    required. 
  262.     
  263.    SHOULD allow integration of new security mechanisms without breaking 
  264.    backwards compatible operation. 
  265.     
  266. >From section 6.2 Authentication: 
  267.    MAY support various levels of authentication security. 
  268.     
  269.    MUST support private authenticated login. 
  270.     
  271.    iSCSI authenticated login MUST be resilient against passive attacks. 
  272.     
  273.    MUST support data origin authentication of its communications; data 
  274.    origin authentication MAY be optional to use. 
  275.  
  276. >From section 6.3 Data Integrity: 
  277.    SHOULD NOT preclude use of additional data integrity protection 
  278.    protocols (IPSec, TLS). 
  279.      
  280. >From section 6.4 Data Confidentiality: 
  281.    MUST provide for the use of a data encryption protocol such as TLS 
  282.    or IPsec ESP to provide data confidentiality between iSCSI endpoints 
  283.     
  284. >From section 7 Management: 
  285.    SHOULD be manageable using standard IP-based management protocols. 
  286.     
  287.    iSCSI protocol document MUST NOT define the management architecture 
  288.    for iSCSI, or make explicit references to management objects such as 
  289.    MIB variables. 
  290.     
  291. >From section 7.1 Naming: 
  292.    MUST support the naming architecture of SAM-2. 
  293.   
  294. Krueger             Informational   Exp. Sept 2002                   5 
  295.  
  296.                iSCSI Reqmnts and Design Considerations     March 2002 
  297.  
  298.  
  299.     
  300.    The means by which an iSCSI resource is located MUST use or extend 
  301.    existing Internet standard resource location methods. 
  302.     
  303.    MUST provide a means of identifying iSCSI targets by a unique 
  304.    identifier that is independent of the path on which it is found. 
  305.     
  306.    The format for the iSCSI names MUST use existing naming authorities. 
  307.     
  308.    An iSCSI name SHOULD be a human readable string in an international 
  309.    character set encoding. 
  310.     
  311.    Standard Internet lookup services SHOULD be used to resolve iSCSI 
  312.    names. 
  313.     
  314.    SHOULD deal with the complications of the new SCSI security 
  315.    architecture. 
  316.     
  317.    iSCSI naming architecture MUST address support of SCSI 3rd party 
  318.    operations such as EXTENDED COPY. 
  319.     
  320. >From section 7.2 Discovery: 
  321.     
  322.    MUST have no impact on the use of current IP network discovery 
  323.    techniques. 
  324.     
  325.    MUST provide some means of determining whether an iSCSI service is 
  326.    available through an IP address. 
  327.     
  328.    SCSI protocol-dependent techniques SHOULD be used for further 
  329.    discovery beyond the iSCSI layer. 
  330.     
  331.    MUST provide a method of discovering, given an IP end point on its 
  332.    well-known port, the list of SCSI targets available to the 
  333.    requestor.  The use of this discovery service MUST be optional. 
  334.     
  335. >From section 8 Internet Accessability. 
  336.     
  337.    SHOULD be scrutinized for denial of service issues and they should 
  338.    be addressed. 
  339.     
  340. >From section 8.2 Firewalls and Proxy Servers 
  341.     
  342.    SHOULD allow deployment where functional and optimizing middle-boxes 
  343.    such as firewalls, proxy servers and NATs are present. 
  344.     
  345.    use of IP addresses and TCP ports SHOULD be firewall friendly. 
  346.     
  347. >From section 8.3 Congestion Control and Transport Selection 
  348.  
  349.    MUST be a good network citizen with TCP-compatible congestion 
  350.    control (as defined in [RFC2914]). 
  351.     
  352.   
  353. Krueger             Informational   Exp. Sept 2002                   6 
  354.  
  355.                iSCSI Reqmnts and Design Considerations     March 2002 
  356.  
  357.  
  358.    iSCSI implementations MUST NOT use multiple connections as a means 
  359.    to avoid transport-layer congestion control. 
  360.     
  361.  
  362. 2. iSCSI Design Considerations 
  363.  
  364.   2.1. General Discussion 
  365.     
  366.    Traditionally, storage controllers (e.g., disk array controllers, 
  367.    tape library controllers) have supported the SCSI-3 protocol and 
  368.    have been attached to computers by SCSI parallel bus or Fibre 
  369.    Channel. 
  370.     
  371.    The IP infrastructure offers compelling advantages for volume/block-
  372.    oriented storage attachment.  It offers the opportunity to take 
  373.    advantage of the performance/cost benefits provided by competition 
  374.    in the Internet marketplace. This could reduce the cost of storage 
  375.    network infrastructure by providing economies arising from the need 
  376.    to install and operate only a single type of network. 
  377.     
  378.    In addition, the IP protocol suite offers the opportunity for a rich 
  379.    array of management, security and QoS solutions.  Organizations may 
  380.    initially choose to operate storage networks based on iSCSI that are 
  381.    independent of (isolated from) their current data networks except 
  382.    for secure routing of storage management traffic.  These 
  383.    organizations anticipate benefits from the high performance/cost of 
  384.    IP equipment and a the opportunity for a unified management 
  385.    architecture.  As security and QoS evolve, it becomes reasonable to 
  386.    build combined networks with shared infrastructure; nevertheless, it 
  387.    is likely that sophisticated users will choose to keep their storage 
  388.    sub-networks isolated to afford the best control of security and QoS 
  389.    to ensure a high-performance environment tuned to storage traffic. 
  390.     
  391.    Mapping SCSI over IP also provides: 
  392.     
  393.     -- Extended distance ranges 
  394.     -- Connectivity to "carrier class" services that support IP
  395.       
  396.    The following applications for iSCSI are contemplated: 
  397.     
  398.     -- Local storage access, consolidation, clustering and pooling (as 
  399.        in the data center) 
  400.     -- Network client access to remote storage (eg. a "storage service 
  401.        provider") 
  402.     -- Local and remote synchronous and asynchronous mirroring between 
  403.        storage controllers 
  404.     -- Local and remote backup and recovery 
  405.     
  406.    iSCSI will support the following topologies: 
  407.     
  408.     -- Point-to-point direct connections 
  409.  
  410.   
  411. Krueger             Informational   Exp. Sept 2002                   7 
  412.  
  413.                iSCSI Reqmnts and Design Considerations     March 2002 
  414.  
  415.  
  416.     -- Dedicated storage LAN, consisting of one or more LAN segments 
  417.     -- Shared LAN, carrying a mix of traditional LAN traffic plus 
  418.        storage traffic 
  419.     -- LAN-to-WAN extension using IP routers or carrier-provided "IP 
  420.        Datatone" 
  421.     -- Private networks and the public Internet 
  422.      
  423.    IP LAN-WAN routers may be used to extend the IP storage network to 
  424.    the wide area, permitting remote disk access (as for a storage 
  425.    utility), synchronous and asynchronous remote mirroring, and remote 
  426.    backup and restore (as for tape vaulting).  In the WAN,  using TCP 
  427.    end-to-end avoids the need for specialized equipment for protocol 
  428.    conversion, ensures data reliability, copes with network congestion, 
  429.    and provides retransmission strategies adapted to WAN delays. 
  430.     
  431.    The iSCSI technology deployment will involve the following elements: 
  432.     (1)  Conclusion of a complete protocol standard and supporting 
  433.          implementations;  
  434.     (2)  Development of Ethernet storage NICs and related driver and 
  435.          protocol software; [NOTE: high-speed applications of iSCSI are 
  436.          expected to require significant portions of the iSCSI/TCP/IP 
  437.          implementation in hardware to achieve the necessary 
  438.          throughput.]  
  439.     (3)  Development of compatible storage controllers; and  
  440.     (4)  The likely development of translating gateways to provide 
  441.          connectivity between the Ethernet storage network and the 
  442.          Fibre Channel and/or parallel-bus SCSI domains. 
  443.     (5)  Development of specifications for iSCSI device management such 
  444.          as MIBs, LDAP or XML schemas, etc. 
  445.     (6)  Development of management and directory service applications 
  446.          to support a robust SAN infrastructure. 
  447.     
  448.    Products could initially be offered for Gigabit Ethernet attachment, 
  449.    with rapid migration to 10 GbE.  For performance competitive with 
  450.    alternative SCSI transports, it will be necessary to implement the 
  451.    performance path of the full protocol stack in hardware.  These new 
  452.    storage NICs might perform full-stack processing of a complete SCSI 
  453.    task, analogous to today's SCSI and Fibre Channel HBAs, and might 
  454.    also support all host protocols that use TCP (NFS, CIFS, HTTP, etc). 
  455.     
  456.    The charter of the IETF IP Storage Working Group (IPSWG) describes 
  457.    the broad goal of mapping SCSI to IP using a transport that has 
  458.    proven congestion avoidance behavior and broad implementation on a 
  459.    variety of platforms.  Within that broad charter, several transport 
  460.    alternatives may be considered.  Initial IPS work focuses on TCP, 
  461.    and this requirements document is restricted to that domain of 
  462.    interest. 
  463.     
  464.  
  465.   2.2. Performance/Cost 
  466.     
  467.  
  468.   
  469. Krueger             Informational   Exp. Sept 2002                   8 
  470.  
  471.                iSCSI Reqmnts and Design Considerations     March 2002 
  472.  
  473.  
  474.    In general, iSCSI MUST allow implementations to equal or improve on 
  475.    the current state of the art for SCSI interconnects.  This goal 
  476.    breaks down into several types of requirement: 
  477.     
  478.    Cost competitive with alternative storage network technologies: 
  479.     
  480.    In order to be adopted by vendors and the user community, the iSCSI 
  481.    protocol MUST enable cost competitive implementations when compared 
  482.    to other SCSI transports (Fibre Channel). 
  483.     
  484.    Low delay communication: 
  485.     
  486.    Conventional storage access is of a stop-and-wait or remote 
  487.    procedure call type.  Applications typically employ very little 
  488.    pipelining of their storage accesses, and so storage access delay 
  489.    directly impacts performance.  The delay imposed by current storage 
  490.    interconnects, including protocol processing, is generally in the 
  491.    range of 100 microseconds.  The use of caching in storage 
  492.    controllers means that many storage accesses complete almost 
  493.    instantly, and so the delay of the interconnect can have a high 
  494.    relative impact on overall performance.  When stop-and-wait IO is 
  495.    used, the delay of the interconnect will affect performance.  The 
  496.    iSCSI protocol SHOULD minimize control overhead, which adds to 
  497.    delay. 
  498.     
  499.    Low host CPU utilization, equal to or better than current 
  500.    technology: 
  501.     
  502.    For competitive performance, the iSCSI protocol MUST allow three key 
  503.    implementation goals to be realized: 
  504.      
  505.    (1)  iSCSI MUST make it possible to build I/O adapters that handle 
  506.         an entire SCSI task, as alternative SCSI transport 
  507.         implementations do.   
  508.    (2)  The protocol SHOULD permit direct data placement ("zero-copy" 
  509.         memory architectures, where the I/O adapter reads or writes 
  510.         host memory exactly once per disk transaction.  
  511.    (3)  The protocol SHOULD NOT impose complex operations on the host 
  512.         software, which would increase host instruction path length 
  513.         relative to alternatives. 
  514.     
  515.    Direct data placement (zero-copy iSCSI): 
  516.     
  517.    Direct data placement refers to iSCSI data being placed directly 
  518.    "off the wire" into the allocated location in memory with no 
  519.    intermediate copies.  Direct data placement significantly reduces 
  520.    the memory bus and I/O bus loading in the endpoint systems, allowing 
  521.    improved performance.  It reduces the memory required for NICs, 
  522.    possibly reducing the cost of these solutions.   
  523.     
  524.    This is an important implementation goal.  In an iSCSI system, each 
  525.    of the end nodes (for example host computer and storage controller) 
  526.  
  527.   
  528. Krueger             Informational   Exp. Sept 2002                   9 
  529.  
  530.                iSCSI Reqmnts and Design Considerations     March 2002 
  531.  
  532.  
  533.    should have ample memory, but the intervening nodes (NIC, switches) 
  534.    typically will not. 
  535.     
  536.    High bandwidth, bandwidth aggregation: 
  537.     
  538.    The bandwidth (transfer rate, MB/sec) supported by storage 
  539.    controllers is rapidly increasing, due to several factors: 
  540.      
  541.      1. Increase in disk spindle and controller performance;  
  542.      2. Use of ever-larger caches, and improved caching algorithms;  
  543.      3. Increased scale of storage controllers (number of supported 
  544.         spindles, speed of interconnects).   
  545.     
  546.    The iSCSI protocol MUST provide for full utilization of available 
  547.    link bandwidth.  The protocol MUST also allow an implementation to 
  548.    exploit parallelism (multiple connections) at the device interfaces 
  549.    and within the interconnect fabric. 
  550.     
  551.    The next two sections further discuss the need for direct data 
  552.    placement and high bandwidth. 
  553.     
  554.  
  555.   2.3. Framing 
  556.  
  557.    Framing refers to the addition of information in a header, or the 
  558.    data stream to allow implementations to locate the boundaries of an 
  559.    iSCSI protocol data unit (PDU) within the TCP byte stream.  There 
  560.    are two technical requirements driving framing: interfacing needs, 
  561.    and accelerated processing needs. 
  562.     
  563.    A framing solution that addresses the "interfacing needs" of the 
  564.    iSCSI protocol will facilitate the implementation of a message-based 
  565.    upper layer protocol (iSCSI) on top of an underlying byte streaming 
  566.    protocol (TCP).  Since TCP is a reliable transport, this can be 
  567.    accomplished by including a length field in the iSCSI header.  
  568.    Finding the protocol frame assumes that the receiver will parse from 
  569.    the beginning of the TCP data stream, and never make a mistake (lose 
  570.    alignment on packet headers). 
  571.     
  572.    The other technical requirement for framing, "accelerated 
  573.    processing", stems from the need to handle increasingly higher data 
  574.    rates in the physical media interface.  Two needs arise from higher 
  575.    data rates: 
  576.      
  577.    (1)  LAN environment - NIC vendors seek ways to provide "zero-copy" 
  578.         methods of moving data directly from the wire into application 
  579.         buffers.  
  580.     
  581.    (2)  WAN environment- the emergence of high bandwidth, high latency, 
  582.         low bit error rate physical media places huge buffer 
  583.         requirements on the physical interface solutions. 
  584.     
  585.   
  586. Krueger             Informational   Exp. Sept 2002                  10 
  587.  
  588.                iSCSI Reqmnts and Design Considerations     March 2002 
  589.  
  590.  
  591.    First, vendors are producing network processing hardware that 
  592.    offloads network protocols to hardware solutions to achieve higher 
  593.    data rates.  The concept of "zero-copy" seeks to store blocks of 
  594.    data in appropriate memory locations (aligned) directly off the 
  595.    wire, even when data is reordered due to packet loss.  This is 
  596.    necessary to drive actual data rates of 10 Gigabit/sec and beyond. 
  597.     
  598.    Secondly, in order for iSCSI to be successful in the WAN arena it 
  599.    must be possible to operate efficiently in high bandwidth, high 
  600.    delay networks.  The emergence of multi-gigabit IP networks with 
  601.    latencies in the tens to hundreds of milliseconds presents a 
  602.    challenge. To fill such large pipes, it is necessary to have tens of 
  603.    megabytes of outstanding requests from the application. In addition, 
  604.    some protocols potentially require tens of megabytes at the 
  605.    transport layer to deal with buffering for reassembly of data when 
  606.    packets are received out-of-order. 
  607.     
  608.    In both cases, the issue is the desire to minimize the amount of 
  609.    memory and memory bandwidth required for iSCSI hardware solutions. 
  610.     
  611.    Consider that a network pipe at 10 Gbps x 200 msec holds 250 MB. 
  612.    [Assume land-based communication with a spot half way around the 
  613.    world at the equator.  Ignore additional distance due to cable 
  614.    routing.  Ignore repeater and switching delays; consider only a 
  615.    speed-of-light delay of 5 microsec/km.  The circumference of the 
  616.    globe at the equator is approx. 40000 km (round-trip delay must be 
  617.    considered to keep the pipe full).  10 Gb/sec x 40000 km x 5 
  618.    microsec/km x B / 8b = 250 MB].  In a conventional TCP 
  619.    implementation, loss of a TCP segment means that stream processing 
  620.    MUST stop until that segment is recovered, which takes at least a 
  621.    time of <network round trip> to accomplish.  Following the example 
  622.    above, an implementation would be obliged to catch 250 MB of data 
  623.    into an anonymous buffer before resuming stream processing; later, 
  624.    this data would need to be moved to its proper location.  Some 
  625.    proponents of iSCSI seek some means of putting data directly where 
  626.    it belongs, and avoiding extra data movement in the case of segment 
  627.    drop.  This is a key concept in understanding the debate behind 
  628.    framing methodologies. 
  629.     
  630.    The framing of the iSCSI protocol impacts both the "interfacing 
  631.    needs" and the "accelerated processing needs", however, while 
  632.    including a length in a header may suffice for the "interfacing 
  633.    needs", it will not serve the direct data placement needs. The 
  634.    framing mechanism developed should allow resynchronization of packet 
  635.    boundaries even in the case where a packet is temporarily missing in 
  636.    the incoming data stream. 
  637.     
  638.  
  639.   2.4. High bandwidth, bandwidth aggregation 
  640.  
  641.    At today's block storage transport throughput, any single link can 
  642.    be saturated by the volume of storage traffic. Scientific data 
  643.   
  644. Krueger             Informational   Exp. Sept 2002                  11 
  645.  
  646.                iSCSI Reqmnts and Design Considerations     March 2002 
  647.  
  648.  
  649.    applications and data replication are examples of storage 
  650.    applications that push the limits of throughput.  
  651.     
  652.    Some applications, such as log updates, streaming tape, and 
  653.    replication, require ordering of updates and thus ordering of SCSI 
  654.    commands. An initiator may maintain ordering by waiting for each 
  655.    update to complete before issuing the next (a.k.a. synchronous 
  656.    updates). However, the throughput of synchronous updates decreases 
  657.    inversely with increases in network distances. 
  658.      
  659.    For greater throughput, the SCSI task queuing mechanism allows an 
  660.    initiator to have multiple commands outstanding at the target 
  661.    simultaneously and to express ordering constraints on the execution 
  662.    of those commands. The task queuing mechanism is only effective if 
  663.    the commands arrive at the target in the order they were presented 
  664.    to the initiator (FIFO order).  The iSCSI standard must provide an 
  665.    ordered transport of SCSI commands, even when commands are sent 
  666.    along different network paths (see Section 5.2 SCSI).  This is 
  667.    referred to as "command ordering". 
  668.  
  669.    The iSCSI protocol MUST operate over a single TCP connection to 
  670.    accomodate lower cost implementations.  To enable higher performance 
  671.    storage devices, the protocol should specify a means to allow 
  672.    operation over multiple connections while maintaining the behavior 
  673.    of a single SCSI port.   This would allow the initiator and target 
  674.    to use multiple network interfaces and multiple paths through the 
  675.    network for increased throughput.  There are a few potential ways to 
  676.    satisfy the multiple path and ordering requirements.  
  677.     
  678.    A popular way to satisfy the multiple-path requirement is to have a 
  679.    driver above the SCSI layer instantiate multiple copies of the SCSI 
  680.    transport, each communicating to the target along a different path. 
  681.    "Wedge" drivers use this technique today to attain high performance. 
  682.    Unfortunately, wedge drivers must wait for acknowledgement of 
  683.    completion of each request (stop-and-wait) to ensure ordered 
  684.    updates. 
  685.     
  686.    Another approach might be for iSCSI protocol to use multiple 
  687.    instances of its underlying transport (e.g. TCP). The iSCSI layer 
  688.    would make these independent transport instances appear as one SCSI 
  689.    transport instance and maintain the ability to do ordered SCSI 
  690.    command queuing. The document will refer to this technique as 
  691.    "connection binding" for convenience. 
  692.     
  693.    The iSCSI protocol SHOULD support connection binding, and it MUST be 
  694.    optional to implement. 
  695.     
  696.    In the presence of connection binding, there are two ways to assign 
  697.    features to connections. In the symmetric approach, all the 
  698.    connections are identical from a feature standpoint. In the 
  699.    asymmetric model, connections have different features. For example, 
  700.    some connections may be used primarily for data transfers whereas 
  701.    others are used primarily for SCSI commands. 
  702.   
  703. Krueger             Informational   Exp. Sept 2002                  12 
  704.  
  705.                iSCSI Reqmnts and Design Considerations     March 2002 
  706.  
  707.  
  708.     
  709.    Since the iSCSI protocol must support the case where there was only 
  710.    one transport connection, the protocol must have command, data, and 
  711.    status travel over the same connection. 
  712.     
  713.    In the case of multiple connections, the iSCSI protocol must keep 
  714.    the command and its associated data and status on the same 
  715.    connection (connection allegiance). Sending data and status on the 
  716.    same connection is desirable because this guarantees that status is 
  717.    received after the data (TCP provides ordered delivery). In the case 
  718.    where each connection is managed by a separate processor, allegiance 
  719.    decreases the need for inter-processor communication.  This 
  720.    symmetric approach is a natural extension of the single connection
  721.    approach. 
  722.     
  723.    An alternate approach that was extensively discussed involved 
  724.    sending all commands on a single connection and the associated data 
  725.    and status on a different connection (asymetric approach). In this 
  726.    scheme, the transport ensures the commands arrive in order. The 
  727.    protocol on the data and status connections is simpler, perhaps 
  728.    lending itself to a simpler realization in hardware.  One 
  729.    disadvantage of this approach is that the recovery procedure is 
  730.    different if a command connection fails vs. a data connection. Some 
  731.    argued that this approach would require greater inter-processor 
  732.    communication when connections are spread across processors.  
  733.      
  734.    The reader may reference the mail archives of the IPS mailing list 
  735.    between June and September of 2000 for extensive discussions on 
  736.    symmetric vs asymmetric connection models. 
  737.  
  738.  
  739. 3. Ease of implementation/complexity of protocol 
  740.     
  741.    Experience has shown that adoption of a protocol by the Internet 
  742.    community is inversely proportional to its complexity.  In addition, 
  743.    the simpler the protocol, the easier it is to diagnose problems.  
  744.    The designers of iSCSI SHOULD strive to fulfill the requirements of 
  745.    the creating a SCSI transport over IP, while keeping the protocol as 
  746.    simple as possible. 
  747.       
  748.    In the interest of simplicity, iSCSI SHOULD minimize optional 
  749.    features.  When features are deemed necessary, the protocol MUST 
  750.    specify feature negotiation at session establishment (login).  The 
  751.    iSCSI transport MUST operate correctly when no optional features are 
  752.    negotiated as well as when individual option negotions are 
  753.    unsuccessful. 
  754.     
  755.  
  756. 4. Reliability and Availability 
  757.  
  758.  
  759.  
  760.   
  761. Krueger             Informational   Exp. Sept 2002                  13 
  762.  
  763.                iSCSI Reqmnts and Design Considerations     March 2002 
  764.  
  765.  
  766.   4.1. Detection of Data Corruption 
  767.  
  768.    There have been several research papers that suggest that the TCP 
  769.    checksum calculation allows a certain number of bit errors to pass 
  770.    undetected [10] [11].   
  771.     
  772.    In order to protect against data corruption, the iSCSI protocol MUST 
  773.    support a data integrity check format for use in digest generation.  
  774.     
  775.    The iSCSI protocol MAY use separate digests for data and headers. In 
  776.    an iSCSI proxy or gateway situation, the iSCSI headers are removed 
  777.    and re-built, and the TCP stream is terminated on either side.  This 
  778.    means that even the TCP checksum is removed and recomputed within 
  779.    the gateway.  To ensure the protection of commands, data, and status 
  780.    the iSCSI protocol MUST include a CRC or other digest mechanism that 
  781.    is computed on the SCSI data block itself, as well as on each 
  782.    command and status message.  Since gateways may strip iSCSI headers 
  783.    and rebuild them, a separate header CRC is required.  Two header 
  784.    digests, one for invariant portions of the header (addresses) and 
  785.    one for the variant portion would provide protection against changes 
  786.    to portions of the header that should never be changed by middle 
  787.    boxes (eg, addresses). 
  788.      
  789.    The iSCSI header format SHOULD be extensible to include other digest 
  790.    calculation methods. 
  791.     
  792.  
  793.   4.2. Recovery 
  794.     
  795.    The SCSI protocol was originally designed for a parallel bus 
  796.    transport that was highly reliable.  SCSI applications tend to 
  797.    assume that transport errors never happen, and when they do, SCSI 
  798.    application recovery tends to be expensive in terms of time and 
  799.    computational resources. 
  800.     
  801.    iSCSI protocol design, while placing an emphasis on simplicity, MUST 
  802.    lead to timely recovery from failure of initiator, target, or 
  803.    connecting network infrastructure (cabling, data path equipment such 
  804.    as routers, etc).   
  805.     
  806.    iSCSI MUST specify recovery methods for non-idempotent requests, 
  807.    such as operations on tape drives. 
  808.     
  809.    The iSCSI protocol error recover mechanism SHOULD take into account 
  810.    fail-over schemes for mirrored targets or highly available storage 
  811.    configurations that provide paths to target data through multiple 
  812.    "storage servers".  This would provide a basis for layered 
  813.    technologies like high availability and clustering. 
  814.     
  815.    The iSCSI protocol SHOULD also provide a method for sessions to be 
  816.    gracefully terminated and restarted that can be initiated by either 
  817.    the initiator or target.  This provides the ability to gracefully 
  818.   
  819. Krueger             Informational   Exp. Sept 2002                  14 
  820.  
  821.                iSCSI Reqmnts and Design Considerations     March 2002 
  822.  
  823.  
  824.    fail over an initiator or target, or reset a target after performing 
  825.    maintenance tasks such as upgrading software. 
  826.     
  827.  
  828. 5. Interoperability 
  829.     
  830.    It must be possible for initiators and targets that implement the 
  831.    required portions of the iSCSI specification to interoperate.  While 
  832.    this requirement is so obvious that it doesn't seem worth 
  833.    mentioning, if the protocol specification contains ambiguous 
  834.    wording, different implementations may not interoperate.  The iSCSI 
  835.    protocol document MUST be clear and unambiguous. 
  836.     
  837.  
  838.   5.1. Internet infrastructure 
  839.     
  840.    The iSCSI protocol MUST: 
  841.     -- be compatible with both IPv4 and IPv6. 
  842.     -- use TCP connections conservatively, keeping in mind there may be 
  843.        many other users of TCP on a given machine. 
  844.      
  845.    The iSCSI protocol MUST NOT require changes to existing Internet 
  846.    protocols and SHOULD minimize required changes to existing TCP/IP 
  847.    implementations. 
  848.     
  849.    iSCSI MUST be designed to allow future substitution of SCTP (for 
  850.    TCP) as an IP transport protocol with minimal changes to iSCSI 
  851.    protocol operation, protocol data unit (PDU) structures and formats.  
  852.    Although not widely implemented today, SCTP has many design features 
  853.    that make it a desirable choice for future iSCSI enhancement.  
  854.  
  855.   5.2. SCSI 
  856.  
  857.    In order to be considered a SCSI transport, the iSCSI standard must 
  858.    comply with the requirements of the SCSI Architecture Model [SAM2] 
  859.    for a SCSI transport.  Any feature SAM2 requires in a valid 
  860.    transport mapping MUST be specified by iSCSI.  The iSCSI protocol 
  861.    document MUST specify for each feature whether it is OPTIONAL, 
  862.    RECOMMENDED or REQUIRED to implement and/or use. 
  863.     
  864.    The SCSI Architectural Model [SAM-2] indicates an expectation that 
  865.    the SCSI  transport provides ordering of commands on an initiator-
  866.    target-LUN granularity.  There has been much discussion on the IPS 
  867.    reflector and in working group meetings regarding the means to 
  868.    ensure this ordering.  The rough consensus is that iSCSI MUST 
  869.    specify strictly ordered delivery of SCSI commands over an iSCSI 
  870.    session between an initiator/target pair, even in the presence of 
  871.    transport errors.  This command ordering mechanism SHOULD seek to 
  872.    minimize the amount of communication necessary across multiple 
  873.    adapters doing transport off-load.  If an iSCSI implementation does 
  874.  
  875.  
  876.   
  877. Krueger             Informational   Exp. Sept 2002                  15 
  878.  
  879.                iSCSI Reqmnts and Design Considerations     March 2002 
  880.  
  881.  
  882.    not require ordering it can instantiate multiple sessions per 
  883.    initiator-target pair.   
  884.     
  885.    iSCSI is intended to be a new SCSI "transport" [SAM2].  As a mapping 
  886.    of SCSI over TCP, iSCSI requires interaction with both T10 and IETF.  
  887.    However, the iSCSI protocol MUST NOT require changes to the SCSI-3 
  888.    command sets and SCSI client code except where SCSI specifications 
  889.    point to "transport dependant" fields and behavior.  For example, 
  890.    changes to SCSI documents will be necessary to reflect lengthier 
  891.    iSCSI target names and potentially lengthier timeouts.  
  892.    Collaboration with T10 will be necessary to achieve this 
  893.    requirement. 
  894.     
  895.    The iSCSI protocol SHOULD track changes to SCSI and the SCSI 
  896.    Architecture Model. 
  897.     
  898.    The iSCSI protocol MUST be capable of supporting all SCSI-3 command 
  899.    sets and device types. The primary focus is on supporting 'larger' 
  900.    devices: host computers and storage controllers (disk arrays, tape 
  901.    libraries).  However, other command sets (printers, scanners) must 
  902.    be supported.  These requirements MUST NOT be construed to mean that 
  903.    iSCSI must be natively implementable on all of today's SCSI devices, 
  904.    which might have limited processing power or memory. 
  905.     
  906.    ACA (Auto Contingent Allegiance) is an optional SCSI mechanism that 
  907.    stops execution of a sequence of dependent SCSI commands when one of 
  908.    them fails.  The situation surrounding it is complex - T10 specifies 
  909.    ACA in SAM2, and hence iSCSI must support it and endeavor to make 
  910.    sure that ACA gets implemented sufficiently (two independent 
  911.    interoperable implementations) to avoid dropping ACA in the 
  912.    transition from Proposed Standard to Draft Standard.  This implies 
  913.    iSCSI SHOULD support ACA implementation. 
  914.     
  915.    The iSCSI protocol MUST allow for the construction of gateways to 
  916.    other SCSI transports, including parallel SCSI [SPI-X] and to SCSI-
  917.    FCP[FCP, FCP-2].  It MUST be possible to construct "translating" 
  918.    gateways so that iSCSI hosts can interoperate with SCSI-X devices; 
  919.    so that SCSI-X devices can communicate over an iSCSI network; and so 
  920.    that SCSI-X hosts can use iSCSI targets (where SCSI-X refers to 
  921.    parallel SCSI, SCSI-FCP, or SCSI over any other transport).  This 
  922.    requirement is implied by support for SAM-2, but is worthy of 
  923.    emphasis. These are true application protocol gateways, and not just 
  924.    bridge/routers.  The different standards have only the SCSI-3 
  925.    command set layer in common.  These gateways are not mere packet 
  926.    forwarders. 
  927.     
  928.    The iSCSI protocol MUST reliably transport SCSI commands from the 
  929.    initiator to the target.  According to [SAM-2, p. 17.] "The function 
  930.    of the service delivery subsystem is to transport an error-free copy 
  931.    of the request or response between the sender and the receiver" 
  932.    [SAM-2, p. 22]. The iSCSI protocol MUST correctly deal with iSCSI 
  933.    packet drop, duplication, corruption, stale packets, and re-
  934.    ordering. 
  935.   
  936. Krueger             Informational   Exp. Sept 2002                  16 
  937.  
  938.                iSCSI Reqmnts and Design Considerations     March 2002 
  939.  
  940.  
  941.     
  942.  
  943. 6. Security Considerations 
  944.  
  945.    In the past, directly attached storage systems have implemented 
  946.    minimal security checks because the physical connection offered 
  947.    little chance for attack.   Transporting block storage (SCSI) over 
  948.    IP opens a whole new opportunity for a variety of malicious attacks.  
  949.    Attacks can take the active form (identity spoofing, man-in-the-
  950.    middle) or the passive form (eavesdropping). 
  951.     
  952.  
  953.   6.1. Extensible Security 
  954.     
  955.    The security services required for communications depends on the 
  956.    individual network configurations and environments.  Organizations 
  957.    are setting up Virtual Private Networks(VPN), also known as 
  958.    Intranets, that will require one set of security functions for 
  959.    communications within the VPN and possibly many different security 
  960.    functions for communications outside the VPN to support 
  961.    geographically separate components.  The iSCSI protocol is 
  962.    applicable to a wide range of internetworking environments that may 
  963.    employ different security policies.  iSCSI MUST provide for strong 
  964.    authentication when increased security is required.  The protocol 
  965.    SHOULD require minimal configuration and overhead in the insecure 
  966.    operation, and allow integration of new security mechanisms without 
  967.    breaking backwards compatible operation. 
  968.     
  969.  
  970.   6.2. Authentication 
  971.     
  972.    The iSCSI protocol MAY support various levels of authentication 
  973.    security, ranging from no authentication to secure authentication 
  974.    using public or private keys. 
  975.     
  976.    The iSCSI protocol MUST support private authenticated login.  
  977.    Authenticated login aids the target in blocking the unauthorized use 
  978.    of SCSI resources.  "Private" authenticated login mandates protected 
  979.    identity exchange (no clear text passwords at a minimum).  Since 
  980.    block storage confidentiality is considered critical in enterprises 
  981.    and many IP networks may have access holes, organizations will want 
  982.    to protect their iSCSI resources. 
  983.     
  984.    The iSCSI authenticated login MUST be resilient against passive 
  985.    attacks since many IP networks are vulnerable to packet inspection. 
  986.     
  987.    In addition, the iSCSI protocol MUST support data origin 
  988.    authentication of its communications; data origin authentication MAY 
  989.    be optional to use.  Data origin authentication is critical since IP 
  990.    networks are vulnerable to source spoofing, where a malicious third 
  991.    party pretends to send packets from the initiator's IP address. 
  992.  
  993.   
  994. Krueger             Informational   Exp. Sept 2002                  17 
  995.  
  996.                iSCSI Reqmnts and Design Considerations     March 2002 
  997.  
  998.  
  999.     
  1000.    These requirements should be met using standard Internet protocols 
  1001.    such as IPsec or TLS. The endpoints may negotiate the authentication 
  1002.    method, optionally none.  
  1003.     
  1004.  
  1005.   6.3. Data Integrity 
  1006.     
  1007.    The iSCSI protocol SHOULD NOT preclude use of additional data 
  1008.    integrity protection protocols (IPSec, TLS). 
  1009.     
  1010.  
  1011.   6.4. Data Confidentiality 
  1012.     
  1013.    Block storage is used for storing sensitive information, where data 
  1014.    confidentiality is critical.  An application may encrypt the data 
  1015.    blocks before writing them to storage - this provides the best 
  1016.    protection for the application. Even if the storage or 
  1017.    communications are compromised, the attacker will have difficulty 
  1018.    reading the data. 
  1019.     
  1020.    In certain environments, encryption may be desired to provide an 
  1021.    extra assurance of confidentiality. An iSCSI implementation MUST 
  1022.    provide for the use of a data encryption protocol such as TLS or 
  1023.    IPsec ESP to provide data confidentiality between iSCSI endpoints. 
  1024.     
  1025.  
  1026. 7. Management 
  1027.     
  1028.    iSCSI implementations SHOULD be manageable using standard IP-based 
  1029.    management protocols.  However, the iSCSI protocol document MUST NOT 
  1030.    define the management architecture for iSCSI within the network 
  1031.    infrastructure.  iSCSI will be yet another resource service within a 
  1032.    complex environment of network resources (printers, file servers, 
  1033.    NAS, application servers, etc).  There will certainly be efforts to 
  1034.    design how the "block storage service" that iSCSI devices provide is 
  1035.    integrated into a comprehensive, shared model, network management 
  1036.    environment.  A "network administrator" (or "storage administrator") 
  1037.    will desire to have integrated applications for assigning user 
  1038.    names, resource names, etc. and indicating access rights.  iSCSI 
  1039.    devices presumably will want to interact with these integrated 
  1040.    network management applications.  The iSCSI protocol document will 
  1041.    not attempt to solve that set of problems, or specify means for 
  1042.    devices to provide management agents.  In fact, there should be no 
  1043.    mention of MIBs or any other means of managing iSCSI devices as 
  1044.    explicit references in the iSCSI protocol document, because 
  1045.    management data and protocols change with the needs of the 
  1046.    environment and the business models of the management applications. 
  1047.     
  1048.  
  1049.  
  1050.  
  1051.   
  1052. Krueger             Informational   Exp. Sept 2002                  18 
  1053.  
  1054.                iSCSI Reqmnts and Design Considerations     March 2002 
  1055.  
  1056.  
  1057.   7.1. Naming 
  1058.     
  1059.    Whenever possible, iSCSI MUST support the naming architecture of 
  1060.    SAM-2.  Deviations and uncertainties MUST be made explicit, and 
  1061.    comments and resolutions worked out between ANSI T10 and the IPS 
  1062.    working group. 
  1063.     
  1064.    The means by which an iSCSI resource is located MUST use or extend 
  1065.    existing Internet standard resource location methods.  RFC 1783 [12] 
  1066.    specifies URL syntax and semantics which should be sufficiently 
  1067.    extensible for the iSCSI resource. 
  1068.     
  1069.    The iSCSI protocol MUST provide a means of identifying an iSCSI 
  1070.    storage device by a unique identifier that is independent of the 
  1071.    path on which it is found.  This name will be used to correlate 
  1072.    alternate paths to the same device.  The format for the iSCSI names 
  1073.    MUST use existing naming authorities, to avoid creating new central 
  1074.    administrative tasks.  An iSCSI name SHOULD be a human readable 
  1075.    string in an international character set encoding. 
  1076.     
  1077.    Standard Internet lookup services SHOULD be used to resolve names. 
  1078.    For example, Domain Name Services (DNS) MAY be used to resolve the 
  1079.    <hostname> portion of a URL to one or multiple IP addresses.  When a 
  1080.    hostname resolves to multiple addresses, these addresses should be 
  1081.    equivalent for functional (possibly not performance) purposes.  This 
  1082.    means that the addresses can be used interchangeably as long as 
  1083.    performance isn't a concern.  For example, the same set of SCSI 
  1084.    targets MUST be accessible from each of these addresses. 
  1085.     
  1086.    An iSCSI device naming scheme MUST interact correctly with the 
  1087.    proposed SCSI security architecture [99-245r9].  Particular 
  1088.    attention must be directed to the proxy naming architecture defined 
  1089.    by the new security model.  In this new model,  a host is identified 
  1090.    by an Access ID, and SCSI Logical Unit Numbers (LUNs) can be mapped 
  1091.    in a manner that gives each AccessID a unique LU map.  Thus, a given 
  1092.    LU within a target may be addressed by different LUNs. 
  1093.     
  1094.    The iSCSI naming architecture MUST address support of SCSI 3rd party 
  1095.    operations such as EXTENDED COPY.  The key issue here relates to the 
  1096.    naming architecture for SCSI LUs - iSCSI must provide a means of 
  1097.    passing a name or handle between parties. iSCSI must specify a means 
  1098.    of providing a name or handle that could be used in the XCOPY 
  1099.    command and fit within the available space allocated by that 
  1100.    command.  And it must be possible, of course, for the XCOPY target 
  1101.    (the third party) to de-reference the name to the correct target and 
  1102.    LU. 
  1103.     
  1104.  
  1105.   7.2. Discovery 
  1106.     
  1107.    iSCSI MUST have no impact on the use of current IP network discovery 
  1108.    techniques.  Network management platforms discover IP addresses and 
  1109.   
  1110. Krueger             Informational   Exp. Sept 2002                  19 
  1111.  
  1112.                iSCSI Reqmnts and Design Considerations     March 2002 
  1113.  
  1114.  
  1115.    have various methods of probing the services available through these 
  1116.    IP addresses.  An iSCSI service should be evident using similar 
  1117.    techniques. 
  1118.     
  1119.    The iSCSI specifications MUST provide some means of determining 
  1120.    whether an iSCSI service is available through an IP address.  It is 
  1121.    expected that iSCSI will be a point of service in a host, just as 
  1122.    SNMP, etc are points of services, associated with a well known port 
  1123.    number. 
  1124.     
  1125.    SCSI protocol-dependent techniques SHOULD be used for further 
  1126.    discovery beyond the iSCSI layer.  Discovery is a complex, multi-
  1127.    layered process.  The SCSI protocol specifications provide specific 
  1128.    commands for discovering LUs and the commands associated with this 
  1129.    process will also work over iSCSI.  
  1130.     
  1131.    The iSCSI protocol MUST provide a method of discovering, given an IP 
  1132.    end point on its well-known port, the list of SCSI targets available 
  1133.    to the requestor.  The use of this discovery service MUST be 
  1134.    optional. 
  1135.     
  1136.    Further discovery guidelines are outside the scope of this document 
  1137.    and may be addressed in separate Informational drafts. 
  1138.  
  1139.  
  1140. 8. Internet Accessibility 
  1141.  
  1142.   8.1. Denial of Service 
  1143.     
  1144.    As with all services, the denial of service by either incorrect 
  1145.    implementations or malicious agents is always a concern.  All 
  1146.    aspects of the iSCSI protocol SHOULD be scrutinized for potential 
  1147.    denial of service issues, and guarded against as much as possible. 
  1148.     
  1149.  
  1150.   8.2. NATs, Firewalls and Proxy servers 
  1151.     
  1152.    NATs (Network Address Translator), firewalls, and proxy servers are 
  1153.    a reality in today's Internet.  These devices present a number of 
  1154.    challenges to device access methods being developed for iSCSI.  For 
  1155.    example, specifying a URL syntax for iSCSI resource connection 
  1156.    allows an initiator to address an iSCSI target device both directly 
  1157.    and through an iSCSI proxy server or NAT.  iSCSI SHOULD allow 
  1158.    deployment where functional and optimizing middle-boxes such as 
  1159.    firewalls, proxy servers and NATs are present. 
  1160.     
  1161.     
  1162.    The iSCSI protocols use of IP addressing and TCP port numbers MUST 
  1163.    be firewall friendly. This means that all connection requests should 
  1164.    normally be addressed to a specific, well-known TCP port.  That way, 
  1165.    firewalls can filter based on source and destination IP addresses, 
  1166.  
  1167.   
  1168. Krueger             Informational   Exp. Sept 2002                  20 
  1169.  
  1170.                iSCSI Reqmnts and Design Considerations     March 2002 
  1171.  
  1172.  
  1173.    and destination (target) port number.  Additional TCP connections 
  1174.    would require different source port numbers (for uniqueness), but 
  1175.    could be opened after a security dialogue on the control channel. 
  1176.     
  1177.    It's important that iSCSI operate through a firewall to provide a 
  1178.    possible means of defending against Denial of Service (DoS) assaults 
  1179.    from less-trusted areas of the network.  It is assumed that a 
  1180.    firewall will have much greater processing power for dismissing 
  1181.    bogus connection requests than end nodes. 
  1182.     
  1183.  
  1184.   8.3. Congestion Control and Transport Selection 
  1185.     
  1186.    The iSCSI protocol MUST be a good network citizen with proven 
  1187.    congestion control (as defined in [RFC2914]). In addition, iSCSI 
  1188.    implementations MUST NOT use multiple connections as a means to 
  1189.    avoid transport-layer congestion control. 
  1190.     
  1191.  
  1192. 9. Definitions 
  1193.  
  1194.    Certain definitions are offered here, with references to the 
  1195.    original document where applicable, in order to clarify the 
  1196.    discussion of requirements.  Definitions without references are the 
  1197.    work of the authors and reviewers of this document. 
  1198.     
  1199.    Logical Unit (LU): A target-resident entity that implements a device 
  1200.    model and executes SCSI commands sent by an application client [SAM-
  1201.    2, sec. 3.1.50, p. 7]. 
  1202.     
  1203.    Logical Unit Number (LUN): A 64-bit identifier for a logical unit 
  1204.    [SAM-2, sec. 3.1.52, p. 7]. 
  1205.     
  1206.    SCSI Device:  A device that is connected to a service delivery 
  1207.    subsystem and supports a SCSI application protocol [SAM-2, sec. 
  1208.    3.1.78, p. 9]. 
  1209.     
  1210.    Service Delivery Port (SDP): A device-resident interface used by the 
  1211.    application client, device server, or task manager to enter and 
  1212.    retrieve requests and responses from the service delivery subsystem.  
  1213.    Synonymous with port (SAM-2 sec. 3.1.61) [SAM-2, sec. 3.1.89, p. 9]. 
  1214.     
  1215.    Target: A SCSI device that receives a SCSI command and directs it to 
  1216.    one or more logical units for execution [SAM-2 sec. 3.1.97, p. 10]. 
  1217.     
  1218.    Task: An object within the logical unit representing the work 
  1219.    associated with a command or a group of linked commands [SAM-2, sec. 
  1220.    3.1.98, p. 10]. 
  1221.     
  1222.    Transaction: A cooperative interaction between two objects, 
  1223.    involving the exchange of information or the execution of some 
  1224.  
  1225.   
  1226. Krueger             Informational   Exp. Sept 2002                  21 
  1227.  
  1228.                iSCSI Reqmnts and Design Considerations     March 2002 
  1229.  
  1230.  
  1231.    service by one object on behalf of the other [SAM-2, sec. 3.1.109, 
  1232.    p. 10]. 
  1233.     
  1234.  
  1235. 10.     References 
  1236.     
  1237.    1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
  1238.       9, RFC 2026, October 1996. 
  1239.     
  1240.    2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
  1241.       Levels", BCP 14, RFC 2119, March 1997 
  1242.     
  1243.    3 [SAM-2] ANSI NCITS.  Weber, Ralph O., editor.  SCSI Architecture 
  1244.      Model -2 (SAM-2).  T10 Project 1157-D.  rev 13, 22 Mar 2000. 
  1245.  
  1246.    4 [SPC-2] ANSI NCITS.  Weber, Ralph O., editor.  SCSI Primary 
  1247.      Commands   2 (SPC-2).  T10 Project 1236-D.  rev 18, 21 May 2000. 
  1248.  
  1249.    5 [CAM-3] ANSI NCITS.  Dallas, William D., editor.  Information 
  1250.      Technology - Common Access Method - 3 (CAM-3)).  X3T10 Project 
  1251.      990D.  rev 3, 16 Mar 1998. 
  1252.  
  1253.    6 [99-245r8] Hafner, Jim.  A Detailed Proposal for Access Controls.  
  1254.      T10/99-245 revision 8, 26 Apr 2000. 
  1255.  
  1256.    7 [SPI-X] ANSI NCITS.  SCSI Parallel Interface - X. 
  1257.  
  1258.    8 [FCP] ANSI NCITS.  SCSI-3 Fibre Channel Protocol [ANSI 
  1259.      X3.269:1996]. 
  1260.  
  1261.    9 [FCP-2] ANSI NCITS.  SCSI-3 Fibre Channel Protocol - 2 [T10/1144-
  1262.      D]. 
  1263.  
  1264.    10 Paxon, V. End-to-end internet packet dynamics, IEEE Transactions 
  1265.      on Networking 7,3 (June 1999) pg 277-292. 
  1266.  
  1267.    11 Stone J., Partridge, C. When the CRC and TCP checksum disagree, 
  1268.      ACM Sigcomm (Sept. 2000). 
  1269.  
  1270.    12 [RFC1783] Berners-Lee, t., et.al.,"Uniform Resource Locators", RFC 
  1271.      1783, December 1994. 
  1272.  
  1273.    13 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 
  1274.      Sept. 2000. 
  1275.  
  1276.                                              
  1277.  
  1278. 11.     Acknowledgements 
  1279.     
  1280.    Special thanks to Julian Satran, IBM and David Black, EMC for their 
  1281.    extensive review comments. 
  1282.     
  1283.   
  1284. Krueger             Informational   Exp. Sept 2002                  22 
  1285.  
  1286.                iSCSI Reqmnts and Design Considerations     March 2002 
  1287.  
  1288.  
  1289.  
  1290. 12.     Author's Addresses 
  1291.     
  1292.    Address comments to: 
  1293.     
  1294.    Marjorie Krueger 
  1295.    Hewlett-Packard Corporation 
  1296.    8000 Foothills Blvd 
  1297.    Roseville, CA 95747-5668, USA 
  1298.    Phone: +1 916 785-2656 
  1299.    Email: marjorie_krueger@hp.com 
  1300.     
  1301.    Randy Haagens 
  1302.    Hewlett-Packard Corporation 
  1303.    8000 Foothills Blvd 
  1304.    Roseville, CA 95747-5668, USA 
  1305.    Phone: +1 916 785-4578 
  1306.    Email: Randy_Haagens@hp.com 
  1307.     
  1308.    Costa Sapuntzakis 
  1309.    Cisco Systems, Inc. 
  1310.    170 W. Tasman Dr. 
  1311.    San Jose, CA 95134, USA 
  1312.    Phone: +1 408 525-5497 
  1313.    Email: csapuntz@cisco.com 
  1314.     
  1315.    Mark Bakke 
  1316.    Cisco Systems, Inc. 
  1317.    6450 Wedgwood Road 
  1318.    Maple Grove, MN 55311 
  1319.    Phone: +1 763 398-1054 
  1320.    Email: mbakke@cisco.com
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.   
  1343. Krueger             Informational   Exp. Sept 2002                  23 
  1344.  
  1345.                iSCSI Reqmnts and Design Considerations     March 2002 
  1346.  
  1347.  
  1348.     
  1349. Full Copyright Statement 
  1350.  
  1351.    "Copyright (C) The Internet Society (2001). All Rights Reserved. 
  1352.    This document and translations of it may be copied and furnished to 
  1353.    others, and derivative works that comment on or otherwise explain it 
  1354.    or assist in its implementation may be prepared, copied, published 
  1355.    and distributed, in whole or in part, without restriction of any 
  1356.    kind, provided that the above copyright notice and this paragraph 
  1357.    are included on all such copies and derivative works. However, this 
  1358.    document itself may not be modified in any way, such as by removing 
  1359.    the copyright notice or references to the Internet Society or other 
  1360.    Internet organizations, except as needed for the purpose of 
  1361.    developing Internet standards in which case the procedures for 
  1362.    copyrights defined in the Internet Standards process must be 
  1363.    followed, or as required to translate it into languages other than 
  1364.    English. 
  1365.     
  1366.    The limited permissions granted above are perpetual and will not be 
  1367.    revoked by the Internet Society or its successors or assigns. 
  1368.  
  1369.  
  1370.  
  1371.     
  1372.     
  1373.     
  1374.     
  1375.  
  1376.  
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.   
  1396. Krueger             Informational   Exp. Sept 2002                  24 
  1397.