SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI URL scheme



    
    
    David,
    
    You might be right about us facing a change.
    
    Two things drive it.
    
    One is minor - addressing - and using the URL we are trying to make it more
    like
    other things on the net and allow it to fit into the hierarchical structure
    of the net
    instead of the flat SCSI structure.
    
    Walking the bus(es) is anyhow not an option anymore and the URL will come
    from somewhere - a Service Location service or in the extreme (god forbid)
    a local configuration file.
    
    The second (the  view name) is again a form of access-id (as in Jim
    Haffner's scheme adopted by T10) that can be used as a complement or
    instead of the address to
    differentiate users (user is here an OS signature).
    
    I assume that those naming and authorization schemes will evolve into
    structures
    that have many elements in common with other internet services and save us
    the
    expense of rediscovering the wheel again and again.
    
    As for the simple SCSI walk all the buses scheme it is gone anyhow.
    
    Julo
    
    Black_David@emc.com on 02/10/2000 23:56:52
    
    Please respond to Black_David@emc.com
    
    To:   Daniel Smith/Almaden/IBM@IBMUS, ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  iSCSI URL scheme
    
    
    
    
    With my co-chair hat off ... I've had a long-running concern about the URL
    naming in iSCSI that Daniel's example allows me to express concisely ...
    
    > Let's imagine a large array of fast, reliable and featuresome
    storage---an
    > IBM Shark box say.  B-) This box has many user accounts, and is being
    used
    > in the context of a storage service provider.  The login sequence might
    go
    > something like this....
    >
    > I: Hello Shark---I'm an initiator.  My authentication ID is "Robert
    Smith,
    >    Seattle, next to the donut store, hjhhaskjanbt112kg9d988".
    >
    > S: Hello initiator.  I'll be your server---we need a secure connection:
    >    switch to "hjcnneamchjsdkfsdsd394njsdf89423".  (Trivial example.)
    >
    > I: <encrypted> Alright!  I want to connect to
    >    "scsi://niceshark.acme.com/bobsstorage/san3?wwn=0x7b4d72658a7410db"
    
    This query is a *major* departure from SCSI practice at this level.
    The SCSI approach would be more along the lines of:
    
    I: <encrypted> Alright! Show me all your LUNs that I can access.
    
    (i.e., REPORT LUNS) at which point the Initiator then does additional SCSI
    commands to figure out what each LUN actually is.  One of these commands
    could
    be to read (or attempt to read) the WWN for each LUN.  For disk storage
    that
    is
    under a volume manager, there's another round of discovery later on in
    which
    the volume manager reads the volume label and figures out what the storage
    is
    independent of any information that was used to discover it.
    
    Returning to the three examples:
    
    > Then we have a choice...
    >
    > S: <encrypted> Great---off you go and have a nice day.
    >
    > or
    >
    > S: <encrypted> Sorry---you haven't got permission to use that any more/it
    >    doesn't exist.
    
    This is an authorization check that can be implemented by a combination
    of accepting/denying the connection based on the client authentication
    information and/or only reporting the LUNs to which the Initiator has
    access
    (and after an exhaustive search, the Initiator may discover that a LUN it
    used to have access to [based on WWN} doesn't seem to be there any more).
    Fibre Channel makes widespread use of a mechanism similar to the latter at
    the
    target discovery level (nameserver based soft zoning, where the fabric
    nameserver
    only tells an Initiator about Targets it can access, rather than all the
    Targets it
    knows about).
    
    > or (just after they buy more storage)
    >
    > S: <encrypted> Ok, that URL has been changed to
    >   "scsi://bobstorage.san3.acme.com:9003/".  Please come again.
    
    This is a common computer science solution to a large set of problems;
    introduce another level of indirection ;-).  While I understand the
    solution,
    I'm not at all clear on what the problem is and why it needs to be solved
    in this fashion.  There's been a lot of traffic on this, have I missed
    something?
    
    The counterbalance on the other side of this issue is that iSCSI
    should fit into existing SCSI frameworks for storage discovery,
    access, and management (e.g., in operating systems).  Every time a
    new sort of naming is introduced, that integration difficulty goes up
    considerably.  The worked example is that Fibre Channel had to introduce
    WWNs or their equivalent for some fairly obvious functional reasons,
    but introducing WWNs to operating systems that started out only
    understanding parallel SCSI caused no end of pain and suffering.
    
    Something that's going to rear its ugly head here is discovery.  SCSI
    discovery is fundamentally based on a "bus walker" paradigm in which
    low level logic does discovery based on a comprehensive search
    (i.e., try every possible target on the parallel bus).  When Fibre
    Channel introduced WWNs, this broke the "try every possible
    target" approach (can't iterate through every 64 bit WWN and still
    boot quickly), and it was fixed by a multi-round distributed address
    assignment scheme for FC-AL (don't ask ;-) ) and the ability to
    query the nameserver for all known ports in FC-SW.  FWIW, FC-SW
    tried to use LDAP for nameservice and gave up; something considerably
    simpler was implemented.  Among the practical problems that resulted
    from WWN introduction is that booting over Fibre Channel took a while to
    get working because FC broke the typical "first LUN of first target
    contains
    a boot image" mechanism used in boot code.
    
    iSCSI has the opportunity to repeat the Fibre Channel experience of
    changing the way things work in a fashion that will take a while to
    work its way through systems.  If this is done, it needs to be done
    for a good reason.  One question to think about is "If all SCSI targets
    are named by URLs on the server, where do the URLs come from?"
    An answer of the form "yet another config file or set of registry entries"
    is an obstacle to adoption, because tools have to be written to manage
    these, and administrators have to learn how to use them, and ...
    
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    
    


Home

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