SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: SCSI Iniitator port: a simple approach, acceptable?



    
    Folks,
    
    I'm curious to know from this group whether the following is an acceptable
    alternative to the complex issues we're battling with the definition and
    behavior of SCSI Initiator Port (viz a viz, ISID, key=value,etc.).
    
    Make the SCSI Initiator Port = initiator portal group, named by iSCSI Name
    + portal group tag (which would be presented during login).
    
    Pros:
    a) the model is completely symmetric on the initiator and the target side
    b) namespace is managed by any mechanism to identify the portal group tag.
    (For example, the tag could be the position in the SCSI port/module load
    sequence (/dev/scsi[x]) OR one could derive the portal group tag from
    either a MAC or from ipaddress of one of the interfaces in the portal
    group).
    c) the drivers present exactly one channel (SCSI initiator port) for each
    initiator portal group to the upper layers in the OS (how that is
    named/identified to the upper layers may be independent of how it is named
    on the wire, i.e., independent of the portal group tag).
    d) completely static/stable configuration on each boot (though it may
    change, as it can today, between boots if components fail or are changed in
    any way).
    
    Cons:
    a)  we *prohibit more than one session* between an initiator portal group
    and a target portal group (to avoid parallel nexus).  This has the side
    consequence of making it harder to be a bad net-citizen by opening too many
    connections through the same set of network interfaces (you open what you
    want within a session only).
    
    I've always avoided this approach as I expected the "cons" would not be
    acceptable, but I've never actually asked this of the group.
    
    So, what's the 'acceptability' of this approach?
    
    Jim Hafner
    
    
    Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/11/2001 08:58:41 am
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Black_David@emc.com, ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: ISID progress
    
    
    
    
    David,
    
    More comments in line
    
    Jim Hafner
    
    
    Black_David@emc.com on 10/10/2001 03:48:55 pm
    
    To:   Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: ISID progress
    
    
    
    This message is shorter than my last one, so that's
    at least a superficial indication of progress ;-).
    
    Jim and Julian had four comments/objections to the
    notion of using a text key to indicate iSCSI Initiator
    Port Name.  Summarizing and responding:
    
    Jim (a): Optional use of port name is ok as far as SAM-2 is
         concerned, but is odd.
    
    Indeed it is odd, but given the choice between an odd
    mapping of SAM-2 to iSCSI and allowing odd behavior of
    iSCSI implementations, I'll take the former.
    <JLH>
    I'm not sure what "odd behavior of iSCSI implementations" you're referring
    to here.
    </JLH>
    
    Jim (b): Would require at least as much coordination above
         the session level of iSCSI as ISIDs.
    
    That would be incorrect.  128 bits is sufficient to eliminate
    coordination.  The reference for this is an expired Internet-
    Draft, draft-leach-uuids-guids-01.txt, that can still be found
    on the web at:
    
    http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt
    http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html
    
    I'm not seriously proposing that port name generation be done
    in this fashion, but rather providing a widely used counter-
    example to Jim's statement.  Note that a network interface
    MAC is likely to be available to many iSCSI implementations.
    <JLH>
    I glanced through that draft and certainly don't think it is the right
    approach to this problem.  However, if you/we believe that by simply making
    the equivalent of the ISID field or portname text value big enough, we can
    find a solution to the "coordination problem", why can't we just *require*
    that sessions have a SCSI port name (extension to iSCSI Name) that is long
    enough to solve the weak or no coordination problem, instead of making this
    "TBD"?
    
    I've argued that having the SCSI Portname is valuable.  I've argued that
    there wasn't any net value in putting the name in a key because I already
    had the ISID field as part of the "name space for the session endpoint".
    But if the claim is simply the ISID isn't big enough, then I don't have a
    problem with effectively making them bigger (either in the header or in a
    key value).   I've even suggested one way to do that by embedding the
    initiator portal group tag in the value.  But another way is to embed the
    OUI of the HBA (except for the cases where there isn't an HBA) or embed one
    of the MACs of one of the nics (except for the cases where there isn't a
    nic, e.g., dialup), etc.  But we'd have to solve all the possible cases
    (all of which the NDT had to deal with for iSCSI Names in the first place).
    
    So, are we at the point where (for this alternative proposal):
    (a) we just need a bigger (than 2byte ISID) field for the SCSI portname
    extension
    (b) we just need an algorithm that lets each component that wants to
    generate such a name can do so without collision concerns?
    </JLH>
    
    
    
    Jim (c): How to describe model when the text key is optional?
         "Is it that all initiator session endpoints that don't
          provide this text key have *implicit* unique names and
          only when the text key is presented does the name get
          explicit (and then possibly not be unique)? In that case,
          the key would have to be supplied in login next to the
          InitiatorName.
    
    Yes and yes when it's used, in that order.  Jim's comment (a)
    about this being odd applies.
    
    Julian: ... and have as much chances to blow a session as ISID
    
    That would also be incorrect.  As previously stated, ISID conflict
    is fatal to one of the sessions involved (one cannot change the
    ISID and continue), and can occur in any system that opens parallel
    sessions.  This text key conflict need not be fatal (one can
    change the text key and continue negotiation) and can only occur
    in systems that want to use the new port-spanning persistent
    reservation functionality, as other systems won't use the text
    key.  Also see the draft noted in response to Jim (b) above;
    Julian's "have as much chance" language is incorrect.
    <JLH>
    I think this is somewhat misleading about the cost ("fatal").  If we could
    find a reasonable model for "reject: ISID in use" (rather than "blow away
    the old session"), then the "fatal to one of the sessions" is a nit.  This
    would happen on the first exchange of a connection so starting over isn't
    any big deal (we may not even have to require connection drop, just restart
    of the initial message with new ISID).  The same would happen with the key
    as that would have to be somewhere in the pre-full feature phase (but in
    this case it could happen anywhere in that phase).
    </JLH>
    
    As previously noted, I can also deal with requiring conservative
    reuse of ISIDs as a means to address this situation.
    
    
    Thanks,
    --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: Thu Oct 11 17:17:24 2001
7202 messages in chronological order