SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: multiple sessions b/n a pair of WWUIs.



    
    Pierre,
    You are correct when you create a second session from the same (i)SCSI
    Initiator Device (iSCSI Initiator Node) using a different ISID, it becomes
    another (i)SCSI Initiator Delivery PORT (I took some freedom and preceded
    the SCSI PORT with an "i". to denote that it is used with iSCSI, no
    significant in the name it is still a SCSI Delivery Port (SDP), and in this
    case a SCSI Initiator Delivery Port or SIDP or (i)SIDP or .......
    
    There should have  been nothing in my note that tied the (i)SCSI Initiator
    Delivery Port to any HW.  (It can be, but that was not what I was
    addressing.)
    
    As soon as the second session is started, to the same Target Device (but
    with a different ISID), you now have new (i)SCSI Initiator Delivery Port
    and an issue of determining how you handle the delivery of commands, in
    what kind of order, etc.  since the same LUs can be address across the
    different sessions.  This is where the complications of Wedge Drivers
    (active and passive) come into effect.
    
    The value of Multiple Connections per Session, is that they have  built-in
    load balancing and order delivery.  This is usually easier to deal with
    then Multiple SCSI Delivery Ports and Wedge Drivers.
    
    If you reread my note, you should find that we are saying the same thing
    (now that you understand my free use of the "i" ).
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Internet address: hufferd@us.ibm.com
    
    
    Pierre Labat <pierre_labat@hp.com>@ece.cmu.edu on 05/09/2001 09:52:50 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.
    
    
    
    John Hufferd wrote:
    
    > Santosh,
    > I think I am beginning to see the problem.  A given iSCSI Initiator Port
    > can NOT have a second session with the same iSCSI Initiator Port and be
    > consistent with SCSIness.  The second session could be started with
    another
    > ISID, (to the same iSCSI Target Port) but if the session was established
    it
    > would not have any of its commands and data handled via any techniques
    > defined by SCSI or iSCSI.  In fact its use would require a wedge driver.
    > This is the exact confusion I was trying to avoid.  Technically if you
    were
    > actually able to start another Session to the same Target Port, it would
    > be, by definition another iSCSI Initiator Port.   The two different Ports
    > would need to be coordinated by what we have been calling a Wedge Driver.
    >
    > Today, the way we use multiple Fibre Channel Initiator Ports connected to
    > the same Fibre Channel Target Ports is by use of Wedge Drivers.  I think
    > what you are suggesting causes the need for a Wedge Drivers to integrate
    > the iSCSI Initiator Ports.  Not sure that we want to cause this type of
    > thinking, by accident.  One of the reasons for Multiple Connections per
    > Session was to remove the "Hard" need for Wedge Drivers.
    
    John,
    Could you give your exact definition of a iSCSI port.
    Till your mails they were the definition of
    - a "portal" (IP add),
    - a SCSI service delivery port (=session end point from what i hearded in
    Nashua)
    
    It seems that you want to tie the  notion of SCSI service delivery port
    to hardware, the opposite of what was presented in Nashua.
    
    Do i miss something?
    
    I see nothing wrong against SCSI or iSCSI to have two sessions (with 2 #
    ISID) flowing from the same initiator adapter to the same target adapter.
    Each session end point represents a SDP.
    
    Regards,
    
    Pierre
    
    
    >
    >
    > OK, that's what I think our misunderstanding is all about.  If I am
    > mistaken, please set me straight.
    > .
    > .
    > .
    > John L. Hufferd
    > Senior Technical Staff Member (STSM)
    > IBM/SSG San Jose Ca
    > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > Internet address: hufferd@us.ibm.com
    >
    > Santosh Rao <santoshr@cup.hp.com>@cup.hp.com on 05/08/2001 05:44:41 PM
    >
    > Sent by:  santoshr@cup.hp.com
    >
    > To:   John Hufferd/San Jose/IBM@IBMUS
    > cc:   Black_David@emc.com, ips@ece.cmu.edu
    > Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.
    >
    > John,
    >
    > By the name-disc definition, an iSCSI initiator or target port is a
    > logical entity that constitutes the end points of a session.
    >
    > Hence, there never can be 2 sessions b/n the *same* 2  initiator &
    > target port. Each session established spawns a *new* initiator and
    > target iSCSI port.
    >
    > Going by the above semantics, there is always only 1 ISID/TSID per iSCSI
    > Initiator/Target port.
    >
    > Hence, I'm unable to understand your statements below.
    >
    > As for the uniqueness of ISID across all initiators, is there any reason
    > not to allow implementations to do that ? I would have thought that is
    > the most typical use of an ISID and also allows initiators to lookup
    > their target structures based on ISID.
    >
    > Regards,
    > Santosh
    >
    > John Hufferd wrote:
    > >
    > > Also, since a second session by the same iSCSI Initiator Port, to the
    > same
    > > iSCSI Target Port is not, in my opinion "legal", it is not clear to me
    > that
    > > any given iSCSI Port needs any more then one ISID.  I
    > >
    > > Therefore, I suggest that we Not put any such notes, like you suggest,
    in
    > > the draft, but in fact encourage a single ISID/TSID per iSCSI
    > > Initiator/Target Port.
    >
    > > To:   Jim Hafner/Almaden/IBM@IBMUS, marjorie_krueger@hp.com
    > > cc:   ips@ece.cmu.edu
    > > Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.
    > >
    > > While Jim's correct ... in Marj's defense, what
    > > she wrote is a fairly obvious way to implement
    > > it, and that might be worth noting in the draft.
    > >
    > > --David
    
    
    
    
    


Home

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