RE: iSCSI Naming and Discovery (Bootstrapping)

["Douglas Otis" <dotis@sanlight.net>]

Charles,

Dynamic Host Configuration Protocol is the first step in bootstrapping;
Lightweight Directory Access Protocol should be the second.  With these very
powerful tools, all overhead needed to communicate with SCSI is done prior
to making any connections.  LDAP would contain knowledge of SCSI defined as
a SCSI service schema.  This technique avoids all real-time authentications
to allow SCSI transport to scale.  The SCSI schema naming conventions for
the boot drive may take the form NETSCSIBOOT:XXXXXXXXXXXX where the
hexadecimal text string of the MAC address of the booting machine is used as
a user name to match against the special drive name.

A schema for a SCSI service may look something like:

   Object Class: SCSI IP Network Services
     Description: Used to define Network

     SIPNSMacro: SCSINET OBJECT-CLASS
         SUBCLASS Portal
         MUST CONTAIN {
             Primary_IP,
             T_PROT,
             E_PROT,
             Targets,
             Permission}
         MAY CONTAIN {
             Secondary_IP,
             Internal_IP}

     TARGET_DEF OBJECT-CLASS
         SUBCLASS OF Targets
         MAY CONTAIN {
                     Port_Identifier,
                     Port_WWN,
                     LUNS,
                     Link}

     LUN_DEF OBJECT-CLASS
         SUBCLASS OF LUNS
         MAY CONTAIN {
                     HI_LUN,
                     WWNNS}...

Standardizing using LDAP rather than vendor specific tools ensures more
rapid acceptance and use of this protocol both within Internet and in
enterprise environments.  In single user scenarios, a simple flat file may
suffice in defining SCSI services either as registry entries or as /etc
files.

The provider would only advertise his authentication server via a DNS to the
public.  If the client's browser had a plug-in that knew how to talk to a
SCSI device, it could allow the user to type
SCSI://my.storage.com/my_stuff and a pop-up would request a password or use
a stored password to then access the authentication server at this location
to look for the drives under my_stuff.  Once the needed information was
exchanged between the authentication server and the client, the SCSI driver
would then have all the binary information required to access the SCSI
portal (not advertised via DNS).  The authentication server would return a
structure as indicated prior together with a one-time secret for a cookie
exchange.  LDAP has a Java interface, so perhaps Java was used.  There is
sufficient documentation for accessing LDAP, whereas there is little if any
for vendor specific management tools.  Vendor specific management tools
could easily construct a database exchange that would populate the
documented LDAP database however.

Should there be a third-party command that is required to transverse the IP,
it should be a port on the back-side of a portal that has already been
connected to yet another portal.  This connection may have been established
in response to the authentication or done in a prior fashion.  The port on
the back of the portal would have a SCSI address and would map into yet
another SCSI address within the realm of the other Portal.  Again, even this
translation would not be handled by the client nor should it be as it would
be in the domain of the provider.  The provider would be required to make
the permission and translation table prior to authentication. Perhaps the
translation table was made at the time of installation.  At no point in
time, would the client be able to change this table.  The SCSI space would
be as defined in the permission list and remains static upon authentication.

<snip>
>
> One problem with the existing SCSI discovery mechanisms for logical units,
> of course, is that they don't scale well when the universe of
> logical units
> becomes large.
>
> With that in mind, I was tempted to assert that the storage naming service
> should help us find the location of an LU directly, using it's world wide
> name.  As I think about this, however, I suspect that storage
> management at
> this level of granularity is best done by the vendors who supply
> such tools.
>
> <snip>
>
> Charles
>