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

[julian_satran@il.ibm.com]

Jim,

The "URL like" target address and view are sent o the target as part of the
text-message at
login. If authenthication is being done then this will be part of the
message that follows the
exchange that establishes the authenticated channel.

Julo

"Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 29/09/2000 18:07:54

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]





Julo,

Yet another method for determining the mapping of LUs to LUNs for given
initiator?

You already have vendor-specific ways (in FC that will surely get ported to
iSCSI), the T10 standardized way with AccessID enrollment or with a
TransportID (for iSCSI, which is still TBD), and the login authentication
process (however that ends up getting defined).

Also, your comment implies that the URL is sent to the target in a mode
similar to an http-type protocol.  Where is this protocol defined in the
draft?  Is it part of the Text message in the login authentication?

Jim Hafner


julian_satran@il.ibm.com@ece.cmu.edu on 09-29-2000 06:14:44 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]





I would add that we wanted the path to be an additional identifier that the
target could use
to determine what collection of LUs to present to the initiator.

Julo

csapuntz@csapuntz-u1.cisco.com on 23/09/2000 05:00:33

Please respond to csapuntz@csapuntz-u1.cisco.com

To:   "IP Storage" <IPS@ece.cmu.edu>
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]





Just for clarification... I was not proposing to add the extended
URL scheme for the transport spec. It isn't necessary.

In this thread, Doug makes an excellent point about LDAP being a
superior mechanism for describing how to connect to the
storage. Directory services such as LDAP, as Doug has pointed out,
will be critical to managing large quantities of storage. A host can
ask such a directory service for a list of storage devices it should
mount and how to connect to those storage devices. The query against
the directory server that returns this information can be based on
machine ID, user ID, operating system ID, or even the owner's
birthday. One of the things discovery will end up doing, no doubt, is
defining LDAP schemas that describe how to connect to storage
(i.e. use SCTP or TCP, what port, what target name, what LUN, what
WWN, how to authenticate, etc.).

However, there is one place where the transport protocol has to define
a name: third party commands. There needs to be some kind of global
name which the initiator can pass to the target. The name must be
distillable into a string. The target must understand the name and
be able to use the information to establish a connection to another target.

One could say that the string that is passed is not specified by the
standard but instead specified by some management software. I think
this will lead to poor interoperability.

The SCSI URL-type name is the current proposal for target name.

Why is SCSI target name made up of a hostname + a path? Why is the
hostname + path passed on connection setup? There are two reasons.
I think NAT and IPv6 makes passing hostnames rather than addresses in
protocols more desirable. Hostnames can be re-resolved as you cross
addressing boundaries. The path is there so that the name can
support multiple targets behind a single IP address without having
to add entries to the DNS server. At Cisco, for example,
I have no control over the local DNS servers and cannot
add DNS entries for the ATAPI DVD and floppy in my computer.

_Costa