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

[julian_satran@il.ibm.com]

Although I think that this a very interesting and relevant thread and we
are only
scraping its surface can't we just postpone it until after we have the
protocol fixed and
we start handling discovery and management?

Julo
---------------------- Forwarded by Julian Satran/Haifa/IBM on 27/09/2000
19:01 ---------------------------





csapuntz@cisco.com on 18/09/2000 09:11:24

Please respond to csapuntz@cisco.com

To:   IP Storage <IPS@ece.cmu.edu>
cc:   csapuntz@cisco.com (bcc: Julian Satran/Haifa/IBM)

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






Peter Johansson <PJohansson@ACM.org> on 18/09/2000 01:03:10

Please respond to Peter Johansson <PJohansson@ACM.org>

To:   IP Storage <IPS@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)

Subject:  Re: iSCSI: 2.2.6. Naming & mapping





At 11:37 AM 9/17/00, John Hufferd/San Jose/IBM wrote:

>As specified by Jim Hafner, there is no need and we should not  do what
>you suggest.  We have talked this through before, many, many times, and
>the answer has always come out the same.  PLEASE, lets not go there again.

Jim Hafner's observation (that mandatory presence of a unique ID, on a per
LU basis, in EVPD appears to be destined for adoption within SPC-2) only
reinforces that part of the discussion with which I already agree. It is
desirable to have command set-dependent methods to determine the unique ID
for a LU. Matter closed?

It might also be desirable to have transport-dependent mechanisms to
specify unique IDs for those LUs whose existence is discoverable by
transport-dependent methods. I think this is still open to discussion.

There's not much I can respond to in your comment above, John, because "...
we have talked this through before ..." doesn't constitute much of a
technical argument.




Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson@ACM.org







"Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 18/09/2000 18:31:04

Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>

To:   csapuntz@cisco.com
cc:   IPS@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)

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






Costa,

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