SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: value of Session ID



    
    
    Jim,
    
    The 2 IDs where not a mimic of IP.  Back in prehistory when we attempted
    and measured on a "connection-per-LUN" and later one-connection-target the
    IP addresses where enough to bind initiator and target. When we went for
    multiple connections we needed something to relate the connections and a
    mechanism in which each party provided its own piece (an id of its own
    internal structure) was convenient.   The only role it plays now is binding
    connections into a session. Attaching meaning or external scope to the IDs
    is not what we had in mind but it is not unconceivable (if it has meaning
    and if it is not "yet another way" of doing something that we know how to
    do today).
    
    I thought it can be used to create multiple sessions between 2 endpoints
    but I am not confident that I understand all the implications and where the
    value proposition is.
    
    Julo
    
    "Jim Hafner" <hafner@almaden.ibm.com> on 29/03/2001 22:50:08
    
    Please respond to "Jim Hafner" <hafner@almaden.ibm.com>
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: value of Session ID
    
    
    
    
    Folks,
    
    I know this is bordering on heresy, but I'm trying to understand the value
    of the Session ID (ISID+TSID) in the iSCSI protocol.
    
    My understanding is that this was an attempt to mimic the S_ID and D_ID
    components of the FCP payloads.  Consequently, the ISID would mean the SCSI
    "initiator identifier" and the TSID would be the "target identifier".
    Additionally, the SessionID would then uniquely define the SAM-2 I_T nexus
    object from the perspective of the SCSI domain.
    
    The problem I see is a question of scoping.  In FCP, the S_ID and D_ID are
    imposed from the outside (by the network configuration) on the initiator
    and target.  This also means that they are both externally visible to
    parties other than the initiator and target AND each are unique within a
    fabric (SCSI domain).   As such they suffice both in the context of
    "initiator and target identifiers" AND for the purpose of identifying a
    nexus (internal within a target and, as a bonus, externally in the domain
    itself).
    
    In iSCSI, the identifiers are generated internal to the initiator and
    target.  Consequently, they only have meaning in the context of the
    internal relationship between the initiator and target. They do not provide
    either external visibility or uniqueness within the "SCSI domain".
    Additionally, as currently defined, they are not even necessarily unique
    internal to a target device.   As a result, I'm having trouble
    understanding what they're to be used for.
    
    Clearly, between the iSCSI layer and the SCSI layer within a target device
    (and implicitly to the device server within a logical unit in that target
    device), there must be some unique "handle" that gets associated to the I_T
    nexus in order to distinguish associations like "where does the device
    server return data for a command as it hands the data context down through
    the layers", who sent the command (for the purposes of checking
    reservations), etc.   In effect the target at least needs an internally
    unique pointer for the session context that it can pass around between
    layers.
    
    For half the problem (internal uniqueness), one possible solution is to
    require that the target generate it's TSID in such a way that the resulting
    SessionID is unique within the target.  This seems artificial as it
    effectively defines the internal algorithm that the target uses for it's
    pointers.   The alternative is to just leave this "pointer" to the
    implementation -- but then what value is the SessionID?
    
    Your collective guidance is welcome!
    
    Jim Hafner
    
    
    
    
    


Home

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