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

["Douglas Otis" <dotis@sanlight.net>]

Daniel,

SCSI is not HTTP and does not provide a human interface as a basis for
communication.  Ownership of naming abstractions vary from the perspective
of the client to that of the provider.  The provider may not wish to share
management of these naming abstractions with the client and vise-versa.
Rather than attempting to keep a permanent naming abstraction as globally
shared between both provider and client, these abstractions should be
meaningful to the human dealing with the names.  For the client it may be
Tom, Dick, and Harry, and for the provider it could be Shelf A, E, and N.
By keeping these abstractions independent of the transport layer, it allows
each end to use such means as LDAP servers to join these views in a coherent
fashion.  Your IT manager will insist you not concern yourself with the IP
of your workstation, as he has control of these assignments through DHCP and
LDAP servers, the same should be true for a networked version of SCSI.

Do not forget the large task of authentication that may also be managed by
either the provider or the client.  By keeping the transport as plain as
possible, these naming abstractions can become as complex as required
without affecting the transport specification.  Implanting names into SCSI
is a mistake and should be corrected as it limits this valuable freedom.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Daniel Smith
> Sent: Monday, September 18, 2000 5:25 PM
> To: ips@ece.cmu.edu
> Subject: Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
> 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
> >
> >
> >
> >
>
>