SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: login issue - partial consensus call



    
    I am not now advocating the TSID centric SSID.  I in fact have my doubts
    that any such change is worth the effort.  (Last minute changes to any
    architecture/design is always fraught with potential unseen problems).
    Especially since Jim Hafner, laid out an approach for getting the ISID
    assigned.  However, independent of that, I think a fair hearing should be
    held.
    
    OK, OK,  now for my cut at the TSID remembering on a re-login.  I think the
    issue is the thought that the iSCSI Initiator would want to re-establish
    the same session or at least the same Nexus with the Target.  I also think
    the point is that with the current design, the initiator would be able to
    perhaps save the ISID, in some way, that it used last.  If it is the Target
    that creates the SSID, and thereby fills in the ISID, at the end of the
    Logon, the Initiator could save the generated (by Target ISID) as easily as
    it could save one that it created.  So I do not think we added either any
    problem here or solved anything relative to the reestablishment of a Nexus.
    
    One thing we must remember is that we also have all SW iSCSI Initiator
    nodes, so we already must support the capability to have dynamically
    established ISIDs.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com
    
    
    "Eddy Quicksall" <eddy_quicksall@ivivity.com>@ece.cmu.edu on 09/07/2001
    10:42:49 AM
    
    Please respond to <eddy_quicksall@ivivity.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   Jim Hafner/Almaden/IBM@IBMUS, <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI: login issue - partial consensus call
    
    
    
    Jim,
    
    Thanks. You're right about the more complex naming structure.
    
    The more I think about this ... the more I think the TSID should be what is
    used.
    
    Part of the problem with the ISID is: How are you going to have a central
    layer in OS's that already exist but also fit into SCSI for those systems?
    That is why I thru up the thought of another naming convention.
    
    The only problem with the TSID that I see now is what Millikarjun pointed
    out ... if you wanted to reset after a crash, how would you figure out the
    TSID? If no one can present a solution to that, I'll get off my band wagon.
    
    Eddy
    
    -----Original Message-----
    From: Jim Hafner [mailto:hafner@almaden.ibm.com]
    Sent: Friday, September 07, 2001 12:09 PM
    To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    
    Eddy,
    
    I think one way to view your proposal (and one which I more or less dropped
    sometime ago, but may want to resurrect) is that you're assigning the
    Initiator Name to the SCSI Initiator Port and the Host Name to the SCSI
    Device.  You've effectively created a two-level naming scheme.
    
    You propose then a Text keys=HostName and InitiatorName and both of these
    have to get sent during login.
    
    Rather than turning the cart over completely, let's take a different tact
    for this.
    
    Let's have the iSCSI Initiator Name name the host (as we've had it so far).
    Let's allow for an 'extension' on this name that further qualifies a
    subcomponent.  So, if my InitiatorName="iqn.2001-08.com.jlh", then I have
    have statically assigned names like "iqn.2001-08.com.jlh:port1", etc. Each
    of these new names would name a SCSI Initiator Port and within that name
    space we'd have uniqueness of ISIDs.
    Now, I can get this information over the wire at login with either
       initiatorname=iqn.2001-08.com.jlh
       portext=port1
    (and use initiatorname for authentication)
    OR
       initiatorname=iqn.2001-08.com.jlh:port1
    AND make the presumption that everything before the : in the initiator name
    is used for authentication, the rest is ignored.
    
    Note that the 'port1' extension could easily be the portal group tag.
    
    Note also, that the first of these is equivalent to your proposal, just
    with keys reversed.  However, your proposal would require two levels of
    world wide uniqueness, since both the hostname and the initiatorname would
    have to be unique. (Unless the initiator name was assigned to adapters from
    the outside in exactly the same manner as we need to assign ISIDs today!)
    
    In short, the effect is exactly the same as you propose, either by adding a
    different key explicitly or implicitly.
    
    I abandoned this approach for two reasons.  First, it added more complexity
    to the basic protocol (more keys or more assumptions). Second, the "port1"
    extension is just another name 'self-assigned' by the initiator (through
    some undefined mechanism) and I didn't see any functional difference
    between assignment of this extension and assignment of ISIDs!  The ISID was
    already an 'extension' to the initiatorname and already in the login
    request.  What functional gain did we get by adding another field where we
    put another 'piece' of a name?
    
    Jim Hafner
    
    
    "Eddy Quicksall" <eddy_quicksall@ivivity.com> on 09/07/2001 06:33:10 am
    
    Please respond to <eddy_quicksall@ivivity.com>
    
    To:   Jim Hafner/Almaden/IBM@IBMUS, <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI: login issue - partial consensus call
    
    
    
    Jim,
    
    Thanks, this helps a lot.
    
    The problem I had was that David Black said:
    
      "the iSCSI Initiator Name is supposed to refer to the
       host into which the HBAs are plugged"
    
    So I was trying to rationalize that. The problem I have with this is that
    it
    will be difficult to get all HBAs and OS's to agree on how this
    InitiatorName is going to become known to the HBAs and how the ISIDs are
    going to be distributed to the HBAs. Especially when the best place for a
    SCSI HBA in the windows world is as a Miniport.
    
    So, I was thinking that the definition of InitiatorName should allow this.
    I
    think your explanation below does allow this. I think my original message
    way down below fits your definition.
    
    So, I attempted to suggest a definition of InitiatorName that would allow
    both what you have said and what David said. When I said "unique", I was a
    bit vague. What I meant was that the host could have several InitiatorNames
    and each InitiatorName would be responsible for his creation of unique
    ISID's.
    
    Now, I'm wondering why we are even trying to use the ISID to reset a
    session
    when we should be using the TSID ... because the target can produce unique
    TSIDs and use that to identify the session much more easily than using the
    combination of InitiatorName and ISID.
    
    Someone mentioned an issue with authentication ... that process should not
    require all HBA names to be known. Two things here:
    
      1) if several HBAs are being shared by a common driver, the driver is
    well
    aware of the HBA manufacturer (it is probably produced by the HBA
    manufacturer) and the driver can be the InitiatorName (and hence distribute
    ISIDs to its HBAs).
      2) but that does not fully cover the authentication point. i.e., that the
    OS should be the apex for authentication. For that, we could have a
    HostName. If an HBA does not want to play in that arena (because it is on a
    private network), it could give a NULL for the HostName.
    
    Eddy
    
    -----Original Message-----
    From: Jim Hafner [mailto:hafner@almaden.ibm.com]
    Sent: Thursday, September 06, 2001 4:55 PM
    To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    
    Eddy,
    
    I'll try to take a crack at this question.
    
    The problem is that the word "initiator" is being overused in these
    discussions (same for "target").  I personally try to make a distinction in
    every case, even if I sound pendantic.
    
    In almost all cases in the iSCSI spec (and I think rev-08 will make this
    explicit), the word 'initiator' means iSCSI initiator (an iSCSI Node doing
    client stuff) unless otherwise qualified.  The iSCSI Initiator has exactly
    one iSCSI Name.  An OS may have one such iSCSI Initiator in it, or it may
    have several (depends on how you want to use them, but access rights etc
    are supposed to be bound to the name, so fewer nodes in an OS means fewer
    names means less configuration and more consistent views of storage within
    the host).   An iSCSI Initiator can have multiple network interfaces,
    lumped into groups (portal groups) with the property that within each
    portal group, a cross network interface multiple connection session can be
    built.  For example, I could have two iSCSI HBAs, each with dual ethernet
    ports (and possibly different addresses for each port).  Ideally, this is
    one iSCS Initiator, with two portal groups.
    
    The other context of 'initiator' is "SCSI Initiator" and that further
    qualifies to "SCSI Initiator Port" and 'SCSI initiator device'.  In our
    case, the SCSI initiator device is 'attached' to the iSCSI Initiator (node)
    and there is only one such attachment.  The SCSI Initiator ports are (as
    defined now) the initiator end points of sessions (are dynamically
    created).
    
    I hope that much is clear. I've annotated your questions/quotes below with
    my interpretation of which context the word initiator is implied.
    
    Jim Hafner
    
    
    "Eddy Quicksall" <eddy_quicksall@ivivity.com>@ece.cmu.edu on 09/06/2001
    09:50:02 am
    
    Please respond to <eddy_quicksall@ivivity.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   <Black_David@emc.com>, <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI: login issue - partial consensus call
    
    
    
    David,
    
    Now, I'm really confused...
    
    I just read through the spec and I don't see where it mentions the
    "Initiator" as you have presented it below. Can you please give me a
    reference?
    
    Section 1.1 appears to define "initiator" as:
    
      Clients of a SCSI interface are called "initiators".
    <JLH> iSCSI Initiator" </JLH>
    
      Initiators are one endpoint of a SCSI transport.
    <JLH> I think this is "iSCSI Initiator"; however, it is not unrelated to
    the binding of one iSCSI Initiator to one SCSI Initiator Device, so you can
    probably read both of these terms here.
    </JLH>
    
    Section 1.2.1 says:
    
       The group of TCP connections that link an initiator
       with a target, form a session (loosely equivalent to a SCSI I-T
       nexus).
     <JLH> iSCSI Initiator and iSCSI Target; it's the session which is loosely
    equivalent to an I_T nexus.
     </JLH>
    
    That does not seem to be consistent with your definition.
    
    In parallel SCSI, you can have two different initiators
    <JLH>
    SCSI Initiator Port
    </JLH> talking to the same
    target
    <JLH>
    SCSI Target Port
    </JLH>
     with both initiators on the same host
    <JLH>
    SCSI Initiator Device (or perhaps even finer than that)
    </JLH>
    ... your use of Initiator
    <JLH> to interpret David, I think this was iSCSI Initiator Node
    </JLH>
    does not seem to be consistent that that because you would allow only one
    Initiator (the host).
    
    Also, if the InitiatorName is the name of the host, how does an independent
    HBA find out the name?
    
    I would like to propose that "Initiator" refers to that end point which is
    maintaining unique ISID's. I believe this definition would be consistent
    with all that is in the spec.
    <JLH>
    I'm not clear what you mean with this definition.  "unique ISIDs" with
    respect to a particular target or globally unique?  The later is not a
    requirement.  The former is a requirement.  However, "maintaining" is
    ambiguous.  If an iSCSI Initiator Node partitions its ISID space among its
    portal groups (think HBAs here as is being discussed), then each portal
    group is maintaining its portion of the ISID space according to the
    uniqueness rules, but it's also true that by the simple act of
    partitioning, the iSCSI Initiator Node is doing the same thing.  So who is
    the "maintainer" in your case, the node or the portal group?
    </JLH>
    
    Eddy
    
    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Thursday, September 06, 2001 11:42 AM
    To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    Nope, the iSCSI Initiator Name is supposed to refer to the
    host into which the HBAs are plugged (or, more precisely,
    the OS instance using the HBAs for systems that support multiple
    OS instances).  If we were to change the naming approach to
    associate Initiator identities with network interfaces, this
    particular issue gets easier, but we'd have to take another
    hard look at why multiple sessions are allowed between the
    same Initiator and Target (ditto multiple connections per
    session).
    
    --David
    
    > -----Original Message-----
    > From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
    > Sent: Thursday, September 06, 2001 10:57 AM
    > To: Nick.Martin@compaq.com; ips@ece.cmu.edu
    > Subject: RE: iSCSI: login issue - partial consensus call
    >
    >
    > But wouldn't the two different vendors you mention below have
    > different
    > iSCSI Initiator Names? Remember, the Initiator is not the
    > host, it is the
    > HBA in this case.
    >
    > If two different HBA's are going to play together then a
    > common driver would
    > be used and the driver would provide the iSCSI Initiator
    > Name. Then, the
    > ISID would be properly maintained by the driver.
    >
    > Think of the Initiator Name as the owner of the ISID's for that name.
    >
    > Eddy
    >
    > -----Original Message-----
    > From: Martin, Nick [mailto:Nick.Martin@compaq.com]
    > Sent: Wednesday, September 05, 2001 5:50 PM
    > To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu
    > Subject: RE: iSCSI: login issue - partial consensus call
    >
    >
    > Marj,
    >
    > You mention vendors not knowing how to play right.
    > The problem is that iSCSI does not and will not specify how two HBAs
    > from different vendors installed in the same Initiator should or could
    > get a range of ISIDs for their exclusive use.  This will be operating
    > system specific and vendor defined.  It is uncertain that the
    > same tool
    > or repository would be used by all HBA vendors in any environment.
    > Given this, accidental overlap in ISID space is not unlikely.
    >
    > Given that there is no one way to play right, we must make sure that
    > everyone can at least play nice.
    >
    > My expectation is that sessions are infrequently established and long
    > lived.  ISIDs may be re-used at will by their current owners.  When no
    > "already owned" ISIDs are available, or an attempt to re-use
    > an "already
    > owned" ISID failed, and HBA would need to a) "probe" for a
    > new available
    > ISID or b) fail the request to establish the session.
    > Session recovery
    > should not be attempted unless a session is known to have failed.
    >
    > If tools are available, and the administrator has used them correctly,
    > then HBAs will not collide in ISID space.  If the tools are not
    > available or were not used correctly, I would hope the second HBA can
    > still attempt to come up without impacting the sessions established by
    > the first.
    >
    > Again, I state my support for a login with existing ISID harmlessly
    > fails (the Target state does not change) unless a session recovery
    > indicator is set.  Also if a session recovery indicator is
    > set, and the
    > ISID is not in use (by this Initiator at this Target), the login also
    > fails.
    >
    > Thanks,
    > Nick
    > -----Original Message-----
    > From: KRUEGER,MARJORIE (HP-Roseville,ex1)
    > [mailto:marjorie_krueger@hp.com]
    > Sent: Friday, August 31, 2001 12:09 PM
    > To: Martin, Nick; ips@ece.cmu.edu
    > Subject: RE: iSCSI: login issue - partial consensus call
    >
    >
    > > In particular this enables independent agents within the same
    > initiator to
    > > attempt a login without knowing all ISIDs in use by other agents.
    > Each
    > > agent would know the ISID of sessions it had successfully
    > established,
    > but
    > > not the ISIDs for sessions established by others.  It can use the
    > ISIDs it
    > > knows to recover sessions it owns.  If an agent gets a  failure
    > attempting
    > to
    > > establish a new session, it would pick a different ISID and
    > > retry (or just quit), rather than disrupting a session of another
    > agent.
    >
    > The intent of the presentation on SCSI/iSCSI modeling, and the text in
    > the
    > draft, is to illustrate how this example is not a recommended
    > implementation
    > choice due to the probability of violating the SCSI/iSCSI
    > rules pointed
    > out.
    > If the "independant agents" had partitioned the ISID space,
    > there would
    > be
    > no collision on login and no time wasted.  Your illustrated
    > implementation
    > could spend significant time "trying" ISID's in use by the "other
    > agents".
    >
    > However, I'm starting to have more sympathy with Julian's concerns due
    > to
    > the apparent risks of different vendors' initiator implementations not
    > following the rules.
    >
    > I just imagined having vendor A's HBA installed and happily servicing
    > applications, installing vendor B's "plug-n-play" implementation, and
    > having
    > all A's sessions aborted cause B doesn't know how to play right :-(
    >
    > Marj
    >
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Sat Sep 08 03:17:12 2001
6464 messages in chronological order