Re: Third party naming vis-a-vis iSCSI

[owner-ips@ece.cmu.edu]

Jim,

Did you have a chance to took at the current mapping commands I've set is
iSCSI?
It would be  nice if they become part of SPC and fix the hole of "protocol
specific"
to general purpose addresses. In fact the result in copy managers having
a de-facto local DNS for mapping for the length of the session and that is
more effective than having them handle all the time mapping.

Regards,
Julo

hafner@almaden.ibm.com on 06/07/2000 19:56:45

Please respond to hafner@almaden.ibm.com

To:   "IPS (E-mail)" <ips@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Third party naming vis-a-vis iSCSI






Here's my promised suggestion for third-party naming.

There are two approaches, one fully integrated into SCSI (and so
independent of iSCSI, though iSCSI can best take advantage of it). The
other approach is more attuned to iSCSI, though could be used in other
(probably future) transports.

The real problem in this space is not in the higher application layers
which can do naming in anyway they want, so long as there is an application
that can translate from one form to another.  (So a URL can get "resolved"
by different application layers into an ethernet MAC and IP port, etc.) The
problem is that an arbitrary naming scheme doesn't map well into existing
SCSI paramter data where third party addresses are used (e.g., third party
reservations, RAID commands like XDWRITE, extended copy, etc.).   The
biggest problem in that space is the fact that SCSI has only (at the
moment) set aside fixed sized fields for this purpose (and we know iSCSI is
going to need much longer names).  In some cases, this field is 8 bytes
(e.g., third party reservations) and in others 16 bytes (bytes 12-27 in
extended copy target descriptors; I'm referring here to the identifier of
the "target device" and not the logical unit within that device).

The first suggestion, then is to use the existing fixed field (and only 8
bytes of that) of third party addressing as an "alias" field.  The
requesting initiator will (through a mechanism described later) define for
the target a translation mapping of this alias to the transport specific
identifier of the target (e.g., the <hostname> portion of the url, the FC
WWN, the parallel SCSI address).  A flag bit or field (TBD for each usage)
will indicate that this is an alias field and not a specific address
identifier.  Using aliases in this way, we don't need to change the size of
the fields currently dedicated to third party addresses and we don't need
to change their existing usage.

Here are the two approaches for an initiator to define the
alias<->thirdparty mapping. Note, in all cases, (without a completely
different protocol) the mapping would be initiator specific, not a global
aliasing.

1) Within iSCSI, a Text command could define the mapping.
Advantages:
a) you'd only need to change SPC-2 to allow for alias-type usage, and leave
the mapping to "the transport".
b) it would apply to all third-party addressing contexts.
Disadvantages:
a) there's a disassociation between the actual mapping and the use of the
mapping (that is, state must be maintained) and so all the issues about
state (persistence, etc) have to be addressed.
b) it's not clear how other transports could take advantage of this.

2)an additional "chunk" of the parameter data could be used to define the
alias.  For example, in extended copy, an additional "page" of parameter
data can define the mapping for that instance of the command.
Advantages:
a) can be used in all transports and future transports
b) is a general extensible mechanism
c) has state only for the context of the command itself
d) can handle whatever size of device identifier you want (e.g.,
arbitrarily long <hostname>) - that's because you can define the parameter
data in this way.
Disadvantages
a) would require more changes to SPC-2 (both alias usage and the definition
of mapping), and would (might?) affect any command where third-party
addressing is used.

As for how logical units are referenced within a target, the existing
mechanisms of LUN and Proxy Token (from access controls) are sufficient.
In all cases, the harder part is finding the device.  SCSI already knows
how to find the logical unit within the device.  But I don't see a
fundamental problem with adding this logical unit identifier (in whatever
form you like, LUN, Proxy Token, EVPD data) as part of the alias mapping.
The subtle issue is that in some cases there is no logical unit to
reference (e.g., third party reservations reference an initiator, not a
target).

Political comment:  After having worked with the T10 guys over the last
year or so, I find them very amenable to additions/changes to SCSI so long
as it doesn't break anything and that it meets someones perceived need.  I
think the issues raised here meet both those requirements.  So, I wouldn't
be reluctant (if I were more active in this iSCSI thing) to take specific
proposals to T10 to enhance what iSCSI can do.

Jim Hafner