Date: Mon, 21 Jul 2008 19:43:58 -0400 From: Tarl Neustaedter Subject: [2008/466]iSCSI SPARC Openboot support Sender: Tarl.Neustaedter@Sun.Com To: one-pager@Sun.Com Message-id: <48851F3E.6070509@sun.com> Organization: Sun Microsystems, Scalable Systems Group MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_YTX7a4uv3yfMRZN4AcRGxA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16pre (X11/20080705) Status: RO Content-Length: 7612 This is a multi-part message in MIME format. --Boundary_(ID_YTX7a4uv3yfMRZN4AcRGxA) Content-type: text/plain; format=flowed; charset=ISO-8859-15 Content-transfer-encoding: 7BIT --Boundary_(ID_YTX7a4uv3yfMRZN4AcRGxA) Content-type: text/plain; name=iscsi-onepager.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=iscsi-onepager.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iSCSI SPARC Openboot support 1.2. Name of Document Author/Supplier: Tarl Neustaedter 1.3. Date of This Document: 09-May-2008 1.3.1. Date this project was conceived: Q1 2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: (Unknown at this time) 1.4.2. The ARC(s) you expect to review your project: FWARC 1.4.3. The Director/VP who is "Sponsoring" this project: Mike Sanfrantello 1.4.4. The name of your business unit: Common Software 1.5. Email Aliases: 1.5.1. Responsible Manager: chad.solomon@sun.com 1.5.2. Responsible Engineer: tarl.neustaedter@sun.com 1.5.3. Marketing Manager: margaret.hamburger@sun.com 1.5.4. Interest List: iscsi-interest@sun.com 2. Project Summary 2.1. Project Description: Add ability for SPARCs to boot off iSCSI targets, for customers who wish to avoid locally-attached disks. This can be particularly relevant for blade customers, as it may be convenient to create a storage farm some significant physical distance away from the CPU racks. iSCSI also can provide more flexibility in how disks are partitioned, allowing an iSCSI target to export many root disks (for many booting hosts), which are actually contained within a single physical disk. Since a boot disk only requires around 10GB of storage, a single 1 TB disk could support 100 booting blades. 2.2. Risks and Assumptions: - Expect to re-use code from previous WANboot project, if this doesn't work, it may be necessary to implement a second IP stack. - There have been complications with proprietary specifications being used in iSCSI in the past (notably, Microsoft's iBFT). At this point we don't know of any specifications blocking us, but the history for Linux implementors serves as a caution. 3. Business Summary 3.1. Problem Area: Customers would like to use iSCSI disks as root (boot) disks. This provides another configuration option to IT planners in how they lay out their labs. 3.2. Market/Requester: System Group 3.3. Business Justification: iSCSI is needed to remain compatible with and competitive with both Linux and Windows sites. iSCSI is encroaching on the traditional "network boot" infrastructure. 3.4. Competitive Analysis: The market currently supplies NICs with iSCSI BIOS ROM extensions to allow windows & Linux systems to boot from iSCSI disks. By providing iSCSI support in openboot, we would be able to compete on this check-off item. 3.5. Opportunity Window/Exposure: No specific window, this project is to catch up with the market. 3.6. How will you know when you are done?: On putback of code which can boot from Solaris installed on an iSCSI disk. 4. Technical Description: 4.1. Details: Will implement this as a Openboot dropin in forth, similar to the existing implementations of tftpboot and wanboot. This will provide us the ability to use iSCSI over any existing (or future) working NIC FCode. This will require re-using significant portions of Wanboot to obtain a TCP stack (tftpboot uses only UDP, but iSCSI requires TCP), and will also re-use significant portions existing common SCSI code to build the SCSI packets which will be sent over IP. The boot command is expected to be based on the net-boot format last modified in FWARC 2004/461 (OBP/TFTP Wanboot extensions): boot net,iscsi,,,,, \ ,, Where is the IP address of the iSCSI target, is the pathname of the boot target on disk (e.g., "kadb"), is the IP address of the booting client (this host), is the IP address of the router if going off LAN, is how many times an iSCSI read will be attempted, is ignored, allows specifying LAN routing boundaries. 4.2. Bug/RFE Number(s): None at this time. 4.3. In Scope: The current Solaris support for iSCSI boot is dependent on how BIOS passes information to Windows - notably iBFT. We might need to modify Solaris to deal with a more SPARC-centric way of passing data from PROM to OS (i.e., not scan through memory looking for magic values). 4.4. Out of Scope: N/A 4.5. Interfaces: - OBP Command interface (boot command for network devices). See FWARC 2002/461 for current version. - Add property /chosen:iscsi-target to tell Solaris where in the network to find the root disk. 4.6. Doc Impact: - OBP commands reference - Platform installation guides 4.7. Admin/Config Impact: - Booting from an iSCSI target will obviously be different than booting off a standard SCSI disk or network boot from tftp. - Configuring DHCP to specify booting from an iSCSI target will change 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: Only Openboot firmware is directly affected. If Solaris changes are needed, a release will need to be specified. 4.11. Security Impact: This allows specifying a wider range of disks to boot from, and data in transit across public networks could be compromised. 4.12. Dependencies: N/A 5. Reference Documents: RFC 3720 - Internet Small Computer Systems Interface (iSCSI) 6. Resources and Schedule: 6.1. Projected Availability: 6.2. Cost of Effort: 6.3. Cost of Capital Resources: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: Sysfw 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: N/A 6.4.5. Is this a necessary project for OEM agreements: No. 6.4.6. Notes: None yet. 6.4.7. Target RTI Date/Release: N/A 6.4.8. Target Code Design Review Date: N/A 6.4.9. Update approval addition: N/A 6.5. ARC review type: Standard 6.6. ARC Exposure: Open 6.6.1. Rationale: Development speculation, unfunded project at this time. 7. Prototype Availability: 7.1. Prototype Availability: N/A (no particular benefit from prototype vs full implementation) 7.2. Prototype Cost: N/A --Boundary_(ID_YTX7a4uv3yfMRZN4AcRGxA)--