Re: iSCSI: 2.2.6. Naming & mapping

["Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>]

Folks,

In spite of John's request to not go into this topic now (and concentrate
on the protocol stuff), I want to get my two cents in as this is one of my
hot buttons too.

In this space, you have to make a distinction between "name" and "address"
(e.g., ipname, vs ipaddress vs MAC address).  Names are good for two
purposes: (a) management interfaces and (b) passing between third parties.
Addresses are good when an initiator wants to talk to a target and it has
no (well almost no) value for the other purposes.

For names, the amount of information in a name string depends on the
context.  For management interfaces, you'd want to have ipname plus the LU
identifier.  For third party operations, that should be sufficient as well,
but it further depends on the context.  For example, EXTENDED COPY commands
already have mechanisms for either identifying the "device" and the LU  OR
for identifying the LU with LU WWIdentifiers.  The device field is
currently too short (only 8 bytes) but that is being addressed in T10.  The
LU is currently spec'd as LUN, but enhancements to that have been approved
(proxy tokens in access controls -- t10/99-245r9) that solve the third
party addressing problem.

The EVPD page 83h LU WWIdentifier (or whatever it's called) spec'd in SPC-2
has just be made mandatory for SPC-2 (at yesterday's T10 meeting).   So
iSCSI needn't ask this as a requirement.

Frankly, I think iSCSI needs only to spec the mechanism for a host to "walk
the bus" (i.e., how does the host determine what storage devices it should
talk to on the network).  After connecting to that device, the standard
SCSI logical unit discovery takes over and no more is needed from iSCSI.

About LU Views:  I STRONGLY suggest that iSCSI stay away from this topic.
The access controls provides a SCSI solution to this issue that is in fact
well suited to the iSCSI environment. (There will need to be a small
addition to the access controls for iSCSI, namely, TransportIDs, but that's
a joint T10/IPS detail that can be handled later.)  Adding additional
layers on top of that in the iSCSI space is (IMHO) a mistake.

Thanks for giving me the forum for today!

Jim Hafner


John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09-15-2000 12:32:22 AM

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


To:   Pierre Labat <pierre_labat@hp.com>
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: 2.2.6. Naming & mapping




Pierre, You said
"Yes, it is not a transport issue, but why not request that now before
people
start building iSCSI controllers if it simplifies the life of everybody?
I don't know how FC managed to have their WWN but why could not we do the
same thing?"

Again, you mixed concepts, that is a "port" attribute (WWN) which is a
Transport item, and LUs specific names which is a SCSI issue.

However, there are still things associated with iSCSI which may address
some of the things you are interested in.  Specifically, there are reasons
for a Connection to be "bound" to a specific set of LUs   We are defining a
concept of a LU view, that will permit, the storage controller to know what
LU Views to give to any specific connection.   This is of value to the
Storage Controller as an entity, and the names and associations will
probably be saved in the Discovery Database (LDAP). However, this is my
hallucination, and has not been defined by the Workgroup.

The Workgroup has already agreed to work on the items that are needed for
Discovery, etc. in one of the next work assignments following the
definition of the iSCSI protocol.  There will also be the need to have a
process that defines Names and View Mapping (see section 2.2.6).  There
will need to be, of course a way for the setting and naming the LU View
maps.  All of that is beyond the iSCSI protocol specification.  The iSCSI
protocol (2.2.6 & 3.17), however, has specified the protocol needed to
carry the View information.

Now, please lets focus on the iSCSI Transport Protocol Draft and take on
these LU naming issues at the approprate time.

.
.
.
John L. Hufferd