Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2009 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: 15-March-2009 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 unit. 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: - The iSCSI RFCs are sufficiently loose that indepenent implementations have resulted in significantly different choices. The iSCSI OBP stack has been developed against several known implementations, but may have problems with other, untested, implementations. 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 has encroached on the traditional "network boot" infrastructure. Netra is eager for iSCSI, we understand the Telco market particularly wants to allow system storage to be maintained separate from the actual switching and processing power. iSCSI is an item on the Serpa PRD. 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 firmware and Solaris which can boot from Solaris installed on an iSCSI disk. 4. Technical Description: 4.1. Details: Implements an Openboot Package, which is invoked by the existing obp-tftp stack when an iSCSI boot request is detected. This avoids the need of modifying existing network card drivers, since this can be implemented entirely within the Openboot framework. The boot command is expected to be based on the net-boot format last modified in FWARC 2004/461 (OBP/TFTP Wanboot extensions), by adding new keywords: boot net:iscsi-target-ip=,host-ip=,router-ip=, \ subnet-mask=,iscsi-target-name=, iscsi-lun=,iscsi-partition=,iscsi-port= Where is an ip-formatted address (xxx.xxx.xxx.xxx), is the very long iSCSI target name string, an iscsi-formatted lun identifier (xxxx-xxxx-xxxx-xxxx), is partition argument for disk (a, f, ...). is the IP port number, usually 3260, but selectable. In addition, all of the above information may be supplied by DHCP, so the command could become as simple as: boot net:dhcp In the DHCP case, the eight arguments are retrieved from DHCP, see RFC 4173. This specifies a "Root Path" option starting with "iscsi:", which will contain servername, protocol, port, lun and targetname. The servername becomes iscsi-target-ip, the port becomes iscsi-port, the lun becomes iscsi-lun, and targetname becomes iscsi-target-name. The protocol field is required to contain "6" and is meaningless. Note that DHCP does not provide a means of delivering the partition identifier, so any target specified by DHCP must boot from partition "a" (the first partition on the disk). Partition "a" is the normal case, and this limitation is not expected to be a problem. 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 a mechanism by the name of iBFT, which is inappropriate under SPARCs. Solaris is being modified to pick up the appropriate data from properties in /chosen, the more traditional way of passing information from Prom to Solaris in SPARC. Specific chosen properties added: host-ip iscsi-target-ip iscsi-target-name iscsi-initiator-id (name used by OBP in identifying itself) iscsi-network-path (path of network device to reach target) router-ip (optional, not created if zero) subnet-mask (optional, not created if zero) iscsi-port (optional, decimal 3260 if not provided) iscsi-lun (optional, not created if zero) During the boot process, due to differing semantics between Network and Disk device opens, the initial open will specify a network device, but the actual "bootdev" property passed to bootblocks and ufsboot will be contain a pseudo-device reference - the string will most often consist of " /iscsi:a", and Solaris will have to collect further details from the above-mentioned /chosen properties. 4.4. Out of Scope: N/A 4.5. Interfaces: - Modify boot command for network devices, by adding keywords. See FWARC 2004/461 for current version. - Add nine /chosen properties to indicate iSCSI boot details. - Add /iscsi pseudo-device to OBP's root, compatible value of "none". - Add two NVRAM variables, chap-user and chap-password. 4.6. Doc Impact: - OBP commands reference - Platform installation guides 4.7. Admin/Config Impact: - Installing and booting from an iSCSI target will have numerous cosmetic changes from installing on a normal disk. - Configuring DHCP to specify booting from an iSCSI target will require specifying a "Root Path" option. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: The majority of the change will be in Openboot, but small changes to Solaris will have to be delivered in a patch. 4.11. Security Impact: This project allows specifying a wider range of disks to boot from, so data in transit across public networks may be compromised. The only security mechanism supported is CHAP, which has known weaknesses. The weaknesses of CHAP will be aggravated by the mechanism of passing information between PROM and Solaris (NVRAM variables) which is not secured. 4.12. Dependencies: N/A 5. Reference Documents: RFC 3720 - Internet Small Computer Systems Interface (iSCSI) RFC 3721 - iSCSI Naming and Discovery RFC 3722 - String Profile for iSCSI names RFC 3723 - Securing Block Storage protocols over IP RFC 3783 - Command Ordering considerations with iSCSI RFC 4173 - Bootstrapping clients using iSCSI RFC 3980 - T11 NAA naming format for iSCSI RFC 5048 - iSCSI corrections and clarifications PSARC 2008/247 (iSCSI support in Solaris) FWARC 2004/461 (Wanboot) FWARC 2008/466 (this document) 6. Resources and Schedule: 6.1. Projected Availability: N/A 6.2. Cost of Effort: ( removed ) 6.3. Cost of Capital Resources: ( removed ) 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: Now. 7.2. Prototype Cost: N/A