SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: ISID RULE and Discovery sessions




    It is true that  in the discovery session the initiator does not have to specify a TargetName as  the purpose of the discovery session was to discover the targets.
    As such the discovery session is technically a session with the "iSCSI Node" and the only thing that can bring it down is logout or another discovery session with the same InitiatorName and Isid.

    Regards,
    Julo


    "Pittman, Joseph" <Joseph.Pittman@netapp.com>

    25/04/03 21:08

    To
    Julian Satran/Haifa/IBM@IBMIL, Kalman Meth/Haifa/IBM@IBMIL, <csapuntz@cisco.com>, <efri@sangate.com>, <cbm@rose.hp.com>, <ips@ece.cmu.edu>
    cc
    "dl-iscsi-eng" <dl-iscsi-eng@netapp.com>
    Subject
    iSCSI: ISID RULE and Discovery sessions





    iSCSI specification authors and experts,

    My name is Joe Pittman, an engineering at Network Appliance.
    My group has implemented an iSCSI target based on draft 20

    of the iSCSI specification.

    During interoperability testing, we have encountered an initiator
    (Cisco Linux initiator from SourceForge), whose implementers have

    interpreted the ISID RULE differently from the NetApp target

    implementation.  I need an authoritative ruling on the applicability

    of the ISID RULE for Discovery sessions.

    The ISID RULE states the following (draft-ietf-ips-iscsi-20.txt,
    section 3.4.3):

       ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
      Group (SCSI target port), there can only be one session with a given

      value for ISID that identifies the SCSI initiator port.

    Consider the case where an initiator {InitiatorName X, ISID I} has
    created a Discovery session to a target.  Then, without terminating

    this session via LOGOUT, the same initiator {X,I} creates a new

    Normal session to the same target, at the same target portal.  The

    question is, should the target terminate the existing Discovery

    session in order to enforce the ISID RULE?

    Because there is no mention of Discovery sessions vs. Normal sessions
    in the ISID RULE section, my interpretation of the specification

    was that the existing Discovery session MUST be terminated.

    But one of the authors of the Cisco Linux initiator interpreted
    the specification differently.  Here is an excerpt from an e-mail

    message describing his logic:

    > Discovery sessions don't have TargetNames, and the implicit logout
    > only occurs when the InitiatorName, ISID, and TargetName all match.

    > It should thus be impossible for a normal session to logout a

    > discovery session, since the TargetNames for the two sessions can

    > never match.  I think your target has a bug.

    >
    > Discovery sessions don't really connect to a particular iSCSI

    > target.  It's more a connection to the iSCSI Node as a whole.

    > Normal sessions connect to particular iSCSI targets.  This should

    > keep the two session types from conflicting, even if the ISIDs

    > are the same.

    So, will one of you authors rule on this disagreement?  I am
    eager to fix my bug, if my interpretation was in error.

    One followup question:
    Also, if the Cisco interpretation is correct, then does the ISID

    rule apply to two Discovery sessions?  That is, if the target

    receives a second Discovery session while the first Discovery

    session is still active, MUST the target terminate the first

    Discovery session in order to enforce the ISID RULE?

    Thanks in advance for any help you can provide.
    --

    Joe Pittman

    jpittman@netapp.com



Home

Last updated: Mon Apr 28 14:19:33 2003
12549 messages in chronological order