SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    
    
    Jim,
    
    No. The "view" is just a character string (another accesID if you want)
    that will help
    the target understand who the initiator thinks it is talking too.
    The target will make-up the map accordingly.
    
    The view is in fact the "NAME of the VIEW". More than that - in fact the
    whole
    string can be used as a selector but we did not want to force the host name
    to be unique for the view as it is many times done in the "WWW" world
    (nevertheless
    we can't prevent it).
    
    Julo
    
    "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 02/10/2000 18:30:53
    
    Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:
    Subject:  Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
    
    
    
    
    
    Julo,
    
    Are you suggesting that the host send to the target what it thinks the
    LUN->LU map should be (during the login process)?  I think you call this
    LUN Map, the "view".  I don't quite see what the point of this is.  The
    initiator is fully authenticated to the target as is the target to the
    initiator (via whatever cryptographic or non-cryptographic schemes the
    security proposal defines).  After that, the target knows whose talking and
    knows the map (based on configuration information established in any number
    of ways (Access Control commands in-band; vendor specific in-band or
    out-of-band).  I don't see the point of the initiator sending its "view" to
    the target at any point.  If the initiator sends an incorrect view, you've
    just created an error scenario which needs additional definition. In any
    case, the target will send its "view" for that initiator in REPORT LUNS
    SCSI command after login (which is actually the layer that cares about the
    LUN Map at all anyway).
    
    Jim Hafner
    
    
    julian_satran@il.ibm.com@ece.cmu.edu on 10-02-2000 02:09:56 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]
    
    
    
    
    
    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
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:55 2001
6315 messages in chronological order