1. Introduction
    1.1. Project/Component Working Name:
     Solaris iSCSI Target

    1.2. Name of Document Author/Supplier:
     Rick M

    1.3. Date of This Document:
     25-July-2005

    1.4. Name of Major Document Customer(s)/Consumer(s):
     1.4.1. The PAC or CPT you expect to review your project:
         Solaris PAC
     1.4.2. The ARC(s) you expect to review your project:
         PSARC
     1.4.3. The Director/VP who is "Sponsoring" this project:
         Ken.G
     1.4.4. The name of your business unit:
         NWS

2. Project Summary
    2.1. Project Description:
     iSCSI is a standard RFC protocol (RFC3720) for transferring SCSI
     commands and data over the TCP protocol. This project will provide
     an iSCSI Target solution for Solaris.

    2.2. Risks and Assumptions:

     This project does not deliver a black box storage array. e.g., a
     device with management through some management application.

3. Business Summary
    3.1. Problem Area:
     Fibre Channel is the block storage transport of choice today.
     However, Fibre Channel has costs in specialized hardware -
     particularly switches - and requires specialized knowledge to
     manage these switches. iSCSI has the benefit of commodity
     hardware and familiar management software. Solaris should ship
     an iSCSI initiator in S10U1, but to complete the solution space
     Solaris needs this target.

    3.6. How will you know when you are done?:
     Phase I will be complete when the project successfully emulates
     SCSI direct access disks and sequential tape devices and has
     incorporated the project into a Solaris update or marketing
     release.

4. Technical Description:
     4.1. Details:
     Two approaches where looked at to enable iSCSI Target support. One
     thought was to create a device driver which would watch for incoming
     connections from the network and decode the iSCSI protocol and SCSI
     CDBs. Once the CDB was decoded the data would be stored in files.
     Another thought was to create a user land daemon. The pros and cons
     were examined and creating a daemon was determined the appropriate
     approach.

     The daemon uses four threads per I_T nexus to handle the
     asynchronous nature of being a target. The threads communicate by
     passing messages on a queue to indicate what action is required for
     the given stage.

     There are three global threads, one is optional, to deal with
     housekeeping chores. One thread deals with asynchronous I/O complete
     events, one thread which waits for incoming connections to port
     3260 and an optional thread that waits for  network connections on
     the management port.

     The backing store for each lun is a file. This can be a regular
     file or a block special file if the lun is operating in a pass
     through mode as a bridge device.

     Configuration of the daemon is done through a CLI. The CLI encodes
     the parameters as XML strings and sends them to the daemon through
     a door interface. A socket based interface which accepts the same
     XML information is optionally available (security concerns prevent
     this from being enabled by default). Persistent storage of the
     configuration data is also XML based. The XML data is project
     private and will not be exposed to the administrator.

     4.2. Bug/RFE Number(s):
     N/A

     4.3. In Scope:
     The SCSI emulation will support Direct Access disks and Sequential
     tapes.

     4.4. Out of Scope:
     Fibre Channel target support is not provided.
     Full array management support is not provided.

     4.5. Interfaces:
     iscsitgtadm        - CLI used to configure the daemon.
     /var/run/iscsi_tgt_door    - door to access daemon
     /etc/iscsi/tgt_conf.xml    - top level config file.
     Port 3260        - Default protocol port to watch.

     4.6. Doc Impact:
     man page for CLI and administration section for the care and
     feeding of the target.

     4.7. Admin/Config Impact:
     New administration tool

     4.8. HA Impact:
     N/A

     4.9. I18N/L10N Impact:
     The CLI will need to be I18N.

     4.10. Packaging & Delivery:
     New package.

     4.11. Security Impact:
     iSCSI defines login authentication to be None, CHAP, plus a few
     others which are optional. This project will implement CHAP and
     optionally interface with a RADIUS server. Data encryption will use
     IPsec.

     4.12. Dependencies:
     None. This project uses only public Solaris interfaces.

5. Reference Documents:

6. Resources and Schedule:
    6.1. Projected Availability:
     FY06Q4

    6.5. ARC review type: standard

7. Prototype Availability:
    7.1. Prototype Availability:
     A prototype is available which supports all SCSI commands needed to
     emulate a LBA disk through the iSCSI protocol.

    7.2. Prototype Cost:
     5 months - no hardware cost