SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: CmdSN during the Login phase


    • To: ips@ece.cmu.edu
    • Subject: iSCSI: CmdSN during the Login phase
    • From: "Scott M. Ferris" <sferris@acm.org>
    • Date: Mon, 16 Jul 2001 17:26:13 -0500 (CDT)
    • Content-Transfer-Encoding: 7bit
    • Content-Type: text/plain; charset=US-ASCII
    • Sender: owner-ips@ece.cmu.edu

      At what point during the Login Phase of a leading connection (null
    TSID) does a session exist?  
    
      Section 2.10.7 describing CmdSN for the Login PDU indicates that
    when TSID is null, CmdSN indicates the starting Command Sequence
    number for this session.
    
      For interoperability, it is important to define precisely when a
    session exists, so that all initiators and targets agree on when
    CmdSNs are significant, and do not reject or ignore PDUs due to
    differing assumptions of how the CmdSN numbering should be done during
    the Login Phase.
    
    Some of the possible choices for session start are:
    
    1) a session starts before the initiator sends anything, and the Login
       PDU is the first PDU of a session.
    
    2) a session starts when the initiator receives a (possibly partial)
       Login Response with an accept status class and a non-zero TSID, and
       the next PDU sent by the initiator is the first PDU of the session,
       which uses the same CmdSN as the Login PDU.
    
    3) a session starts when the initiator receives a Final Login
       Response, and the next PDU sent by the initiator is the first PDU
       of the session, which uses the same CmdSN as the Login PDU.
    
      After searching through draft 6, I was unable to find anything that
    clearly indicated which if any of the above possibilities was correct,
    or, if more than one is possible, how the initiator and target are
    supposed to determine what CmdSN numbering scheme the other side is
    using for the Login Phase.
    
      The UNH draft-6 initiator appears to use choice #1.  The Cisco
    draft-6 initiator and target use choice #2.  This can cause the UNH
    initiator to hang when trying to login to the Cisco target, since the
    initiator may send a Text PDU with CmdSN 2, while the target is
    waiting for a PDU with CmdSN 1.
    
      Section 1.2.2.2 states that "Status numbering starts after
    Login. During login, there is always only one outstanding command per
    connection and status numbering is not strictly needed but may be used
    as a sanity check."
    
      A similar argument could be made that CmdSN is not needed during the
    Login Phase, suggesting choice #3 may be the simplest. 
    
      I also think section 1.2.2.2 is problematic, as it appears to
    contradict itself by saying that status numbering is not used during
    login, and then follows up saying status numbering may be used during
    login.  
    
    -- 
    Scott M. Ferris,
    sferris@acm.org 
    


Home

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