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

[Daniel Smith <dfsmith@almaden.ibm.com>]

Just in case people are wondering what this proposal is/was (the mailing
list seems to have exploded quite a bit since it was released back in May),
here it is again, with a handful of [modifications] and [comments].
-- 
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010



----------------------------------------------

Subject: iSCSI naming
Date: Mon, 8 May 2000 15:01:17 -0700 (PDT) [mods 18 Sep 2000]

iSCSI naming requirements (first [and a half] iteration)
-------------------------

It is important to have a consistent naming scheme as the basis of a
discovery system for the SCSI over TCP protocol.  A basic set of
requirements is below, and a method is suggested.

Requirements
------------

A name identifies a [SCSI service delivery port], not a LUN.
notes: There may be many thousands of LUNs (and virtual LUNs) on a
connection.
why: The LUNs given to each connection are likely to be dynamic and assigned
by the iSCSI manager.  The iSCSI names are more static and long-lived, and
must be persistent even if the iSCSI manager fails.
notes: A separate naming scheme will document the LUN discovery and naming
mechanism.  [query to LUN 0 to get list of LUNs]

The namespace need not be fundamentally [systematically] enumerable.
notes: FC can be enumerated, the Internet cannot (practically).
why: iSCSI will be deployed on untrusted networks.  Having devices that can
be enumerated are subject to systematic attack.  Also, many devices will be
behind firewall machines, and not even contactable until a login procedure
has taken place---holes in such an enumerated namespace are not acceptable.
notes: Devices on a LAN can be enumerated, and this is acceptable.
notes: Enumeration (listing) by a 3rd party is acceptable.

The names should be as static as possible.
notes: Both in time and location.
why: A name given for one iSCSI device really ought to resolve to the same
device every time, from everywhere. [device here refers to a SCSI service
delivery port, of course the LUs should stay the same too, barring things
like security lock-outs]

The name should not be tied to the network technology.
notes: For example, ethernet MAC address or IPv4/v6 address.
why: To cope with future networking systems, the name of the iSCSI device
should not rely only on aspects of the transport that are liable to become
obsolete, or that are not static enough.
notes: IPv4 addresses may be acceptable on a controlled private network,
however, these names should not be the canonical names as viewed from the
outside. [major problems with NAT if that happens]

The naming scheme must be reliable.
notes: If parts of the network go down, the names must remain intact.
why: iSCSI may form part of the networking infrastructure, meaning that
after power loss, for example, the iSCSI devices will be required to bring up
the rest of the network.  This implies that the devices should be aware of
their own name, if necessary for network stability.  It also implies that
any name service should have redundancy.

The naming scheme should be nice to look at.
why: Long strings of unformatted numbers are horrible. [and prone to typos]

The iSCSI device being addressed should be maskable from observers.
why: The device name may contain valuable (secure) information, so it must be
possible to hide this information from prying network interfaces.
notes: The URL scheme manages this, by separating the hostname from the
device name.

Proposal
--------
We should follow the URL naming scheme for iSCSI devices, thus:
	scsi://<host>/<device>
Where
<host>:=<name>|<name>:<port> is the TCP [destination] identifier...
<name> is the DNS or DDNS host name of the iSCSI device and
<port> is the TCP port number to connect to.

And [<device> should be <service delivery port>]
<device>:=<path>|<path>/<path>|<path>?<argument> is the device identifier
<path> is a text identifier for the device
<argument>:=<argument>|<argument>?<argument> is an argument for the device
[argument escape character was '&' in the original]

The <host> element is reasonably well defined.  However, I would prefer to
keep the <device> element more free-form.  The scsis://<host>/<device> is
also a straightforward extension. [to secure (SSL) iSCSI]

The <device> identifier specifies an iSCSI TCP connection identifier only. 
This may provide access to one or many LUNs that flit in and out of LUN
space.

One caveat is that some (most?) iSCSI devices will not have access to DNS. 
Fortunately, devices (targets) do not need to [query the network to find]
their names except in the case of trying to resolve another device
(target)---i.e., only initiators need DNS resolution.

Here are some fun examples of the things I would want to do as a storage
manager.

The "backup" program does a simple block-to-block copy from one iSCSI device
to another...
	backup scsi://raid.acme.com/lun12 scsi://tape.acme.com/id25
Of course, a more useful operation may be...
	flashcopy scsi://disk.acme.com/12/2 scsi://disk.acme.com/13/2
where the pathnames are ASCII numbers.  (They may even be the WWN or LUN
value.)

This doesn't address the issue of security.  When we have more of those
issues resolved, we might want to issue a command like this...
	kcopy scsis://secure.acme.com/raid12/set2?key=12345?auth=dfsmith
...so that the <device> part, containing the security tokens, is never passed
in the clear over the network.

It may be possible for a manager to transparently interpret the arguments
or pathname into a LUN list in a storage farm.
	iscsi attach scsi://farm.acme.com/tray17?LUN=0x17?LUN=0x18 /dev/scsi2
	iscsi attach scsi://san.acme.com/5A/27/23/99/B7/A2/01/00 /dev/sda

The Text/Response commands in the iSCSI Internet-Draft might be accommodated
thusly:
	iscsitext scsi://tape.scsi.acme.com/cart5 "com.ibm.retension:yes" \
	                                          "com.ibm.eject:now"
	> com.ibm.retension:ok retensioning
	> com.ibm.eject:ok scheduled ETA 2:30

Secure enumeration might be done in the following way, with peculiar
examples of possible Un*x integration.
	iscsi find_domain_manager
	> iscsi.acme.com
	httpsget https://iscsi.acme.com:99/root&auth=dfsmith&key=1234
	> <xml>
	> <target>
	> scsi://unit1.raid.acme.com/
	> <devices>disk1 disk2 disk3 disk4 disk8 disk9</devices>
	> </target>
	>
	> <target>
	> scsi://bigtape.acme.com/racf4
	> <devices>cart57 cart58</devices>
	> </target>
	>
	> <target>
	> scsi://ibmdeskstar75.dfsmith.acme.com/lun1
	> </target>
	> </xml>
	iscsi mount scsi://ibmdeskstar75.dfsmith.acme.com/lun1 /mnt/mydisk
	> /mnt/mydisk: 73564224 blocks available
	tar -cf 'scsi://bigtape.acme.com/racf4/cart57&user=dfsmith' ~/* &
	> [3] 4291
	runsocks dd if=/dev/zero of=scsi://dfsmith.blocks4less.com/disk1 &
	> [4] 4293
And so on.  (Note: I am not an XML expert.)

[Additional notes:

The decision to resolve devices in the host name or in the device name is
really up to the implementer.  Some companies may already have systems in
place for handling the DNS while they have no existing SAN infrastructure. 
Thus the decision to name a particular service delivery port
    scsi://disk26.farm-b.acme.com/
or
    scsi://farm-b.acme.com/disk26
is up to the system designer.

The iSCSI URL names a bundle of LUs (one iSCSI "connection").  People love
to point out that this is a problem if you have multiple entrance ways into
the same SAN, and the same device (say WWN=0x1234) has different LUNs (say
LUN=5 on iscsi://scsi.acme.com/bridge1 and LUN=477 on
iscsi://scsi.acme.com/bridge2).  So don't do that.  Or do that and just live
with it.  Or make sure the different initiator/bridges into the SAN assign
the device the same LUN.  (There isn't really a problem using a LUN in a
global context, as long as it's always attached to its service delivery
port.)  (Having to query every LUN on a port to get the list of WWNs ought
to be addressed by T10, in the same way they covered the "query LUN 0 to get
a list of LUNs" problem.  IMO!)

The security aspects bring up the spectre of LUs being masked out for
different iSCSI initiators on different parts of the net.  This is fun and
nothing to worry about.

These URL names are used in several places, most of which are not related to
the iSCSI transport itself.  (Likewise, html is not particularly related to
HTTP, nor SMTP to metamail.)

First by users (or users by dint of clobbering an html hyperlink) who want
to attach to iSCSI devices.  The names are descriptive and are malleable to
all sorts of marvelous manipulations by the sysadmins.

Second, by directory servers, who can deliver a list of the URLs (and the
LUNs that are accessible therein) to the iSCSI clients.

Third, by iSCSI itself for the 3rd party copy command.  In this case, the
URL specifies the destination SAN and the target LUN is carried in the
additional data field.

]




----------------------------------------------

Jim Hafner/Almaden/IBM wrote:
> 
> I've seen Daniel's proposal before and I still haven't figured out the
> context in which such names are to be used.
> 
> Given that, I'm personally a bit uncomfortable with any naming convention
> that uses LUN values in a global context.  These have no meaning as LUNs
> are host-specific values.  Even worse, LUNs are addresses, not names!
> 
> I have no problem with WWNs in a global context as that is what they are
> for!
> 
> A subtle difficulty, is that a WWN does not give a host an address (either
> for the target or the LU).  Even in SPC-2, EXTENDED COPY's Identification
> Descriptor Target Descriptor Format (sic?) where WWNs are used, says
> "instructs the copy manager to locate a target and logical unit that
> returns a device identification VPD page ..." but gives no hints on how
> that should be done (e.g., walk the bus and do INQUIRY to everything...?).
> 
> The "hostname" and DNS provide a canonical method for getting an address
> for a name, so that part is OK.  The only defined way to get an address
> (LUN) for a LU WWN is by exhaustive INQUIRY to each LU at a given target.
> 
> On the other hand, I can envision how some of these things might work, in a
> well-coordinated and well-managed environment:
> 
>    There is a managing application which has the dual responsibility of
>    managing the targets for their host/LUN mapping configurations and also
>    serves as the "walk the bus" discovery resource for hosts.
> 
>    When the manager (human?) determines the distribution of host/target LU
>    resources (after inventorying both hosts and target LUs), the
>    application will send to the targets whatever host/LUN Mapping (access
>    controls?) commands are necessary to configure them.  Later, when a host
>    boots it queries the application to get its "walk-the-bus" services.  In
>    this, it minimally gets from this application a list of targets that
>    have LUs to which it should have access.  There is no REQUIREMENT at
>    this point for the application to give the host anything more as the
>    normal SCSI LU discovery process per target kicks in.  On the other
>    hand, I can see some value in the host getting more information about
>    the LUs it will see at each target.  In that case, the host could get
>    from the application a list of targets and LU identifiers (these could
>    be LUNs or WWN or both, as you suggested).  The important point here, is
>    that these LUNs are valid only in the context of the requesting HOST and
>    are not global!
> 
>    Note that this process requires clear coordination between the "target
>    configurator" and "host discovery of targets".
> 
> 
> Given an appropriate context for a URL scheme, I'd make two modifications:
> 1) drop the assumption that no LUN means LUN=0.  If no LU qualifier (e.g.,
> no LUN or WWN (or other) is provided), then LUN=0.  In all other cases, the
> alternative names should be sufficient to identify a LU, though, as above,
> finding a LUN address may require extra work.
> 2) add ?ProxyToken=<token> as an additional option here (this coordinates
> well with the changes to EXTENDED COPY approved in the context of the SCSI
> access controls).
> 
> Well, that's another two cents!  I was hoping to save some of this
> discussion until the protocol gets worked out, but ....
> 
> Jim Hafner
> 
> 
> csapuntz@cisco.com@ece.cmu.edu on 09-17-2000 11:11:24 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   IP Storage <IPS@ece.cmu.edu>
> cc:   csapuntz@cisco.com
> Subject:  SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
> 
> 
> 
> 
> Here is a proposal to extend the iSCSI URL scheme to support LUNs and
> WWNs. It was originally proposed by Daniel Smith of IBM Almaden. This
> extension is not required for the iSCSI transport protocol, but may be
> useful for discovery and management.
> 
> A URL for the target has the following form:
> 
> scsi://hostname/path/with/
> 
> A URL referring to a specific LU has the following form:
> 
> scsi://hostname/path/with/?LUN=lunnumber?WWN=wwnnumber
> 
> If no LUN= term appears in the URL, then LUN 0 is assumed.
> 
> The WWN= term is optional. If present, the party should
> verify that the WWN in the LU's Device Identification Inquiry
> Page correspojnds to the WWN.
> 
> Note, the following URL:
> 
> scsi://gsg.cisco.com/tape/?WWN=0a050a4bcdefa
> 
> refers to LUN 0 of target scsi://gsg.cisco.com/tape/. After
> connecting, the initiator should verify that the WWN
> of the LU is 0a050a4bcdefa.
> 
> -Costa
> 
> 
> 
>