Re: Third party naming vis-a-vis iSCSI

[julian_satran@il.ibm.com]

Jim,

Your first solution is what we already did in the working draft (0706).
The only element on which we in fact differ is that we decomposed the
action
in two elements - the address - that is given out by the initiator
and what you call an alias (in the draft it is a SAR) that is set by the
target.
This way the target can manage by himself the small name server in the best
way he sees fit.  This can be extended to several other protocol elements.

The disassociation between mapping and command is not a major impediment as
we
are talking about long and complex commands anyhow and can be even an
advantage
if the commands are repeated as the decoding logic in the target gets
simpler and more
regular.

The one point in which I would like us to interact sometime with T10 is the
logical
unit name and mapping - this messier than the target address mapping - your
access
control merging with LU identification does not make things simpler.

In the current draft we allude to the fact that the proxy mapping has to be
discussed
with T10 but I think the issue is larger than that.

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