RE: iSCSI Naming and Discovery (Bootstrapping)

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Douglas Otis,
You have sent way too much information to make your point, so much that I
do not think I agree with your details. (It continues to have stuff in it
about LUNs and that seems to be not consistent with were the group seems to
be headed -- careful now or we will unleash Jim Hafner on you) :- )

Your point about needing DHCP to get the location of the DNS and LDAP
server seems to be approprate.  Especially since we seem to have addressed
David Black's concerns about having information to get to the approprate
DNS, or its backup and I suppose the LDAP (and the use of NVRAM/EPROM to
hold the customer input information, or last valid settings etc.).

iSCSI Team,
With my Technical Coordinators Hat On:

I think this is a good direction, but we have, even in this narrow area of
boot discovery some work to do to define the unique aspects in detail of
this process.  Though we are moving toward consensus in this direction, we
need much more detail before we can do that.

If some folks would like to volunteer to put together an "iSCSI boot
process" Draft, that would be much appreciated.  Please send me a note
offline (off the Reflector) with your thoughts about what you would like to
do and how you think it should be laid out.  It would really be great if we
had several people on this team.   I would like to move the "iSCSI Boot
process"  off the main flow of messages until we have a Draft to review.
Now this will be closely associated with the Naming  & Discovery, so it
will need to be consistent with that, but I think we have enough
information to start making the "iSCSI Boot Process"  Draft.  (When they
get to something that sounds like a naming issue, the Draft should point to
a yet non existent Naming and Discovery Draft ---> more about that in the
future.)

Hat off.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com


"Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 10/06/2000 05:17:42 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "Charles Monia" <cmonia@NishanSystems.com>, Jim
      Hafner/Almaden/IBM@IBMUS, "David Robinson"
      <David.Robinson@EBay.Sun.COM>
cc:   <IPS@ece.cmu.edu>
Subject:  RE: iSCSI Naming and Discovery (Bootstrapping)



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
>