SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iscsi : changes involving tgt portal group tag.



    
    Santosh,
    
    Some comments in line (the net is that I think you're right, but with a
    slightly different reason in the first case).
    
    Jim Hafner
    
    
    Santosh Rao <santoshr@cup.hp.com>@t10.org on 03/01/2002 06:02:54 PM
    
    Sent by:    owner-t10@t10.org
    
    
    To:    IPS Reflector <ips@ece.cmu.edu>
    cc:    T10 Reflector <t10@t10.org>
    Subject:    iscsi : changes involving tgt portal group tag.
    
    
    
    * From the T10 Reflector (t10@t10.org), posted by:
    * Santosh Rao <santoshr@cup.hp.com>
    *
    All,
    
    I believe iscsi needs to make 2 changes :
    
    1) to mandate persistence of the portal group tag (and thus, persistence
    of its scsi target port identifier).
    
    2) to send the portal group tag (scsi target port identifier) as a part
    of the iscsi login request.
    
    
    The rationale for (1) is :
    --------------------------
    SAM-2 requires scsi port names to be persistent and world-wide-unique.
    (SAM-2 Rev 22 Section 4.7.7). Quoting from SAM-2 :
    
    "A scsi port name shall never change and may be used to persistently
    identify a scsi initiator port or target port...".
    
    iscsi defines scsi target port name as :
    
    iscsi target name + NULL delimiter + 't' + NULL + (0 - 3) bytes of NULL
    padding + 2 byte portal group tag (in big endian format).
    
    In order for the above scsi target port name to meet SAM-2's requirement
    of being persistent, the portal group tag needs to be persistent.
    
    <JLH>
    There are different ways that one can interpret this "persistent" rule. The
    intent was that names shouldn't change over time when *identifying the same
    object*.   What that means is that if the object changes (in any
    discernable way), then the name should change.  So, the object can move to
    a different piece of hardware, but it can still be named the same way.  If
    the object changes, e.g., in this case, reconfigures as a different set of
    network portals with different addressing elements, then I would think that
    the name should change as well.   That's all the persistence one really
    needs.
    
    I'm not sure what that implies about your recommendation.  I don't see any
    problem with it, either.
    </JLH>
    
    The rationale for (2) is :
    --------------------------
    Consider an initiator node establishing multiple sessions to a scsi tgt
    port, with each session established to a subset of the network portals
    within the tgt portal group.
    
    Consider an iscsi transport event involving the re-configuration of
    target portal groups on the iscsi target node. This may be preceeded by
    the iscsi sessions seeing an async message "target requests logout",
    followed by session logout, portal group re-configuration, and then, the
    initiator re-establishes sessions.
    
    Across a transport event that results in such session termination and
    re-establishment, the initiator needs to authenticate that it is still
    speaking to the same [i]scsi target port, in order to ensure that any
    open/active I-T-L nexus traffic on that session is not incorrectly
    routed to a wrong LUN after such a transport event.
    <JLH>
    Under these events, shouldn't all "open/active I_T_L traffic" have been
    aborted, closed or otherwise ended?  So this shouldn't be an issue at all.
    
    Note that the session end-points in such sessions  are individual
    network portals within a portal group (tgt port) and a target
    re-configuration involving the moving of network portals from 1 portal
    group to another can occur.
    
    Following such a re-configuration, if an initiator were to re-establish
    a session to the same session end-points, since there is no addressing
    information carried in the iscsi login request which carries the target
    port identifier, the session may be established to the same network
    portal, but under a different scsi target port and the I-T-L nexus
    traffic incorrectly routed to a different scsi tgt port, resulting in
    potential data corruption.
    
    Other session oriented SCSI transports like FCP and SRP address this
    problem by defining authentication schemes as well and/or explicitly
    carrying the target port identifier in their login requests, which allow
    them to identify such an authentication mis-match.
    
    To prevent such authentication issues, iscsi can send the iscsi target
    port identifier (portal group tag) explicitly in the login request, and
    the login can be rejected by the target on a portal group tag mis-match.
    (if the network portal does not belong to the addressed portal group
    tag).
    <JLH>
    Did you mean for the initiator to send this TPGT?
    </JLH>
    
    Also, on any portal group re-configuration, iscsi targets MUST terminate
    the session to avoid such scenarios as described above.
    <JLH>
    I would have thought that was implicit in the session logout.
    </JLH>
    
    
    Comments ?
    
    <JLH>
    Final comment:
    I think you may have hit an odd corner case.  I think we need a rule that
    says that (visibile) target port reconfiguration should involve new "names"
    (either node or port). That such a reconfiguration should only occur after
    all sessions have been dropped (with all the attendent clearing effects).
    And that including the TPGT in the login with target reject if it isn't
    correct should also be added.
    </JLH>
    
    Regards,
    Santosh
    
    
    
    
    --
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################
    *
    * For T10 Reflector information, send a message with
    * 'info t10' (no quotes) in the message body to majordomo@t10.org
    
    
    


Home

Last updated: Mon Mar 18 18:18:12 2002
9189 messages in chronological order