no DHCP-assigned InitiatorName

I am writing this memo to the IETF IP Storage Working Group to voice my =

concern over the apparent lack of IETF or industry standard for having a =

DHCP server pass an InitiatorName to an iSCSI boot client.

This issue may be something that you are already aware of, and may be =

something that you are already working to address.

(I am going to ignore the related issues of CHAP username and secret)

rfc4173 [http://tools.ietf.org/html/rfc4173 Bootstrapping Clients using =

the Internet Small Computer System Interface (iSCSI) Protocol) defines =

the protocol for passing boot target information to an iSCSI boot client =

via DHCP options. Unfortunately, it does not define a mechanism for =

passing an InitiatorName to be used by the iSCSI boot initiator. The =

omission of this has led to differences in the InitiatorName in =

different iSCSI boot implementations.

Many iSCSI target servers depend upon the iSCSI InitiatorName to control =

visibility to target LUNs. The inability to control InitiatorName =

through DHCP leads to interoperability issues as one tries to =

dynamically move between systems with different iSCSI boot implementations.

I am not familiar with iSNS (Internet Storage Naming Service =

http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName =

probably plays a key role in identification.

I am familiar with several currently available implementations of iSCSI =

initiators ... hardware, firmware, and software. see listing below.

The hardware and firmware implementations of iSCSI boot initiators =

(QLogic, Intel, Broadcom, IBM) allow one to define static initiator and =

target login information in EEPROM on the client. In addition, they all =

support a DHCP assigned iSCSI boot target per RFC 4173.

The etherboot/gPXE implementation only supports assignment of iSCSI boot =

parameters via DHCP.

Implementations generally construct the InitiatorName by trying to =

include the DHCP option 12 hostname. They take a base iSCSI Qualified =

Name prefix and concatenate the hostname supplied by the DHCP server. =

You end up with:

  iqn.1987-05.com.intel:<hostname>
  iqn.2000-01.org.etherboot:<hostname>
  iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
  iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname>

<hostname> represents the hostname provided in DHCP option 12.
<11.22.33.44.55.66> represents the MAC address of the initiator NIC.

This might work fine in a static data-center environment where dedicated =

applications run on dedicated hardware. Even a mixed environment with =

different vendors involved is generally not a problem as long as each =

system is configured individually ... and as long as no system changes =

are required.

However, data centers and data center configurations are not static. =

They frequently have a need to move from one hardware configuration to =

another. Common examples are a planned hardware upgrade of an existing =

system and an emergency hardware replacement for a failed system. A more =

extreme example would be an offsite disaster-recovery scenario.

Machine virtualization tools such as vmWare and Zen facilitate moving =

images between systems, easing the transition between system hardware.

Data center virtualization systems such as Scalent automate assignment =

of SAN-based applications to available servers in the server pool, =

effectively enabling a data center to run any application on any =

available physical or virtual machine.

Migrating iSCSI boot images from one system to another is problematic if =

the iSCSI boot implementations differ between the old hardware and new =

hardware. On many/most commercial iSCSI target servers the =

visibility/mapping/zoning configuration would have to change because of =

the differing iSCSI InitiatorName. This is a problem because it usually =

requires coordination across organizational units.

Take the case where one has an application running on an IBM server =

using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One =

wishes to move this application to an HP server with an Intel NIC that =

supports iSCSI boot. Both iSCSI initiators support DHCP assignment of =

the iSCSI target. However, since the full InitiatorName is not specified =

via DHCP, the SAN administrator must also make a change on the iSCSI SAN =

storage controller in order to make the appropriate LUN(s) visible to =

the new/different initiator name.

Vendor Extensions

Broadcom and IBM seem to have foreseen this oversight in rfc4713. From =

available documentation it is unclear to me whether or not they have =

adopted exactly the same mechanism as a workaround for assigning the =

iSCSI boot initiator name. I am in the process of obtaining hardware so =

that I can verify behavior.

Broadcom documentation indicates that they support a DHCP vendor =

extension that allows one to fully specify the InitiatorName from the =

DHCP server. Support for an option such as this would mean that =

boot-from-iSCSI-SAN images could be moved between systems by only making =

changes on the DHCP server. See =

http://ftp.us.dell.com/network/Bcom_LAN_11.0_4.1_Manual_A01.exe

Draft IBM documentation at =

ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf =

indicates that the initiator name can be set using DHCP vendor option =

203 =85 but it isn=92t very specific =85 and I have not been able to verify=
 this.

I have also been told that the Microsoft WHQL (Windows Hardware Quality =

Labs) requirements for iSCSI boot make reference to =93DHCP option 203=94. =
I =

am trying to obtain these documents.


Conclusion

There needs to be a standard IETF mechanism, perhaps an extension to =

rfc4713, that defines what InitiatorName is to be used when iSCSI booting.

I am interested in participating in the discussion and am willing to =

help however I can.


Michael Howard
Scalent Systems
[email protected]

----

Internet Small Computer Systems Interface (iSCSI)
http://tools.ietf.org/html/rfc3720

Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery
http://tools.ietf.org/html/rfc3721

String Profile for Internet Small Computer
Systems Interface (iSCSI) Names
http://tools.ietf.org/html/rfc3722

Internet Storage Naming Service (iSNS)
http://tools.ietf.org/html/rfc4171

Bootstrapping Clients using the Internet
Small Computer System Interface (iSCSI) Protocol
http://tools.ietf.org/html/rfc4173

----

QLogic
* hardware iSCSI HBAs
* proprietary drivers for Win + Linux
* http://qlogic.com/Products/SAN_products_iSCSI.aspx
* supports DHCP assignment of target parameters

Intel
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >=3D win2k3
* http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=3D15864
* iqn.1987-05.com.intel:<hostname>

Broadcom
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >=3D win2k3
* http://www.broadcom.com/collateral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf
* iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
* Vendor extension DHCP option 43 suboption 203

IBM
* iSCSI NIC firmware in selected blades/servers
* works in conjunction with MSFT initiator under >=3D win2k3
* http://www.alphaworks.ibm.com/tech/sancommander
* ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf
* vendor extension option 203

emBoot
* software PXE/UNDI implementation
* proprietary windows initiator under XP & win2k with netBoot/i
* works with MSFT initiator under >=3D win2k3
* http://emboot.com/iscsiboot.htm

emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i =

products to assign login information to their software initiator. emBoot =

does not support DHCP assignment of iSCSI boot parameters. Therefore, =

the discussion of DHCP assignment of iSCSI boot parameters is not =

applicable to emBoot=92s current products.

etherboot/gPXE
* open source PXE/UNDI/NIC driver implementation
* works with MSFT initiator under >=3D win2k3
* http://etherboot.org/wiki/index.php
* only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473.


THE END
_______________________________________________
Ips mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ips