Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]

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

OK folks,
Lets go over this name thing again.  First off -- the LU names comes ONLY
from the authorized initiator addressing the LU-0 which the Storage
Controller permits the (Authorized) initiator to see (yes each initiator
may see different LUs, and LU numbers, including different LU-0s).

Some of these LUs may be made up of the same storage components but can
have different LU numbers as seen by different (Authorized) Initiators.
The only way of determining the  LUs that an (Authorized) Initiator may
address (other then LU-0) is for the (Authorized) Initiator to first
perform a Report LUNS command to the LU-0 that an(Authorized) Initiator is
presented by the Storage Controller.  Then the (Authorized) Initiator  will
use the information returned by the Report LUNS Command to identify the LU
numbers that can be addressed by this specific (Authorized) initiator.

The Host's (Authorized) Initiator will now be able to issue the  "Inquire"
Command to the LU numbers identified above, and at VPD page number 83h find
the unique name that can be used to identify the LU.  This unique
identifier will be the same regardless of the initiator or LU number used
to get VPD 83h.  It is the matching up of the different LU identifiers
which causes Hosts to understand that they have more then one path to a
given LU.

Now if we understand the above, we can now do a little more about naming.
First understand that only the Hosts which are authorized to address
specific LUs know what the unique names are, and know the corresponding LU
numbers, which can be used by their Initiators.  Hosts that do not have
authorized initiators, can not address the LUs, even if they know the LU
number that is used by another Host's authorized Initiator.  Even two
different Host with authorized Initiators will not necessarily see the
specific LU with the same LU number.

So the value of placing the LU number and ID in a Database is more limited
then you might have otherwise thought.  No system that doesn't already have
the authorization and the capability of acquiring the knowledge about the
LU can  use the information about the LU.

This means that the only systems that can place information about an LU
into the Database are the ones that are capable of directly using that
information, and which are also the ones that can discover the LU
information when ever they startup.

Having said that, there may be management reasons for having an LU id in
the Database.  A few of these reasons are for error reporting, error
diagnostics, throughput analysis, etc.

Below, I will try to explain how the Database may be used with the above
information (By the way,  I am also in agreement with those folks that
believe that the place to record this is in an LDAP Database.)

The most important thing to be recorded, in the LDAP Database, is the
information about the Device (Storage Controllers), and the Hosts.  That
is, after a set of IP discovery processes (to be discussed later) and the
extraction of the approprate MIB information. With the IP discovered
information, about the various storage controllers, an administrator can
assign human understandable names.  It is also possible for an
administrator to have given a name to the Storage Controller before
attaching it onto the general network.  In this case, the Storage
Controller may have already updated the DNS (Distributed Name Server) with
its own IP address and Human name. I would also except, again in this case,
the Management Software to  extracted that information from the DNS and
populate its LDAP Database with the approprate name.

Given that the names are included in the LDAP Database, an administrator
will need to assign the various Storage Controllers to the approprate
hosts, and insure that the hosts have  paths to get to the Storage
Controllers (both physically and logically).  That is, if their is to be a
VPN setup, the  administrator must not only insure that a physical path
exist between the Host and its authorized storage controllers, but that a
logical path exists.  The best way this can be done, of course, is for each
IP entity to have a Human understandable name.

Once the various entities have Human understandable names,  it will be
possible for management software to create a methods that will tell the
initiators what Target IP address they can use, along with what security
tokens to use, etc.  Like wise it should be possible for the management
software to tell the targets what initiators IP addresses are valid and
what security tokens to accept and send etc.

You will notice in the above, there is no talk about the LU names.

At the moment, each Storage Controller has their own proprietary interface
for administrators to use to create LUs and assign them to various
initiators.  This will, in my opinion need to be done also in the iSCSI
environment, and should be done with Human Readable Names.  That is, the
iSCSI Storage Controller will need to understand what LUs go with what Host
initiator names.  It is not clear how the LU names will be associated with
the approprate LU numbers such that they can some how be matched with the
VPD 83h.  It is not even clear that there will be a name associated with a
LU number for a specific Host initiator name.

It might, however, make since that when we define the management process we
might want to provide a way for a Central administrator to assign the
various LU views to a specific Host initiators, for all the Storage
Controllers within some domain.   But without that management approach,
there will not be a way for the Central Management function, to know what
LUs can be addressed without the various Hosts telling it. So I think that
before we start talking about the makeup of a name, we should understand,
how it is created, and how it will be used.

When folks start focusing on Naming, I think we need to put the various
naming approaches into the above scenarios, and then we can begin to
understand what is of use and of value and what is not.  It would also be
useful to take the various proposals, along with the above, and insure that
they some how fit with the Naming and Mapping section (2.2.6) of the iSCSI
Document including the definition of what is a Target Acquired Name (TAN),
and how the Map command (3.17) fits into the same picture.

Would someone like to take up that challenge and extend the above scenario,
that is, carefully layout how they think the names will be created,
discoverd, used, and fit with the above.   I think I have taken this
scenario as far as I can.
.
.
.
John L. Hufferd



csapuntz@csapuntz-u1.cisco.com@ece.cmu.edu on 09/22/2000 07:00:33 PM

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


To:   "IP Storage" <IPS@ece.cmu.edu>
cc:
Subject:  Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]




Just for clarification... I was not proposing to add the extended
URL scheme for the transport spec. It isn't necessary.

In this thread, Doug makes an excellent point about LDAP being a
superior mechanism for describing how to connect to the
storage. Directory services such as LDAP, as Doug has pointed out,
will be critical to managing large quantities of storage. A host can
ask such a directory service for a list of storage devices it should
mount and how to connect to those storage devices. The query against
the directory server that returns this information can be based on
machine ID, user ID, operating system ID, or even the owner's
birthday. One of the things discovery will end up doing, no doubt, is
defining LDAP schemas that describe how to connect to storage
(i.e. use SCTP or TCP, what port, what target name, what LUN, what
WWN, how to authenticate, etc.).

However, there is one place where the transport protocol has to define
a name: third party commands. There needs to be some kind of global
name which the initiator can pass to the target. The name must be
distillable into a string. The target must understand the name and
be able to use the information to establish a connection to another target.

One could say that the string that is passed is not specified by the
standard but instead specified by some management software. I think
this will lead to poor interoperability.

The SCSI URL-type name is the current proposal for target name.

Why is SCSI target name made up of a hostname + a path? Why is the
hostname + path passed on connection setup? There are two reasons.
I think NAT and IPv6 makes passing hostnames rather than addresses in
protocols more desirable. Hostnames can be re-resolved as you cross
addressing boundaries. The path is there so that the name can
support multiple targets behind a single IP address without having
to add entries to the DNS server. At Cisco, for example,
I have no control over the local DNS servers and cannot
add DNS entries for the ATAPI DVD and floppy in my computer.

_Costa