Re: iSCSI: ISID RULE and Discovery sessions

["Mallikarjun C." <cbm@rose.hp.com>]

The "ISID RULE" is designed to ensure that there's only
one I_T Nexus for a valid I and T, IOW no duplicate nexii.

I_T Nexus being a SCSI notion and given that Discovery
sessions don't allow SCSI commands (12.21), I am inclined
to believe that a Discovery session does not fit the definition
of an "I_T Nexus" and consequently is not required to satisfy
the ISID RULE.

A second protocol "feature" that makes me reach this
conclusion is the fact that TargetName is not required to be
specified in the Login Request on Discovery sessions.  This
essentially implies that such Discovery sessions cannot be
associated with a specific iSCSI Node on the target network
entity if the network entity does support multiple iSCSI Nodes.
One cannot obviously apply the "ISID RULE" in this case,
because the identity of the iSCSI Node servicing the Discovery
session is technically unknown.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: "Pittman, Joseph" <Joseph.Pittman@netapp.com>
To: <Julian_Satran@il.ibm.com>; <meth@il.ibm.com>; <csapuntz@cisco.com>; <efri@sangate.com>;
<cbm@rose.hp.com>; <ips@ece.cmu.edu>
Cc: "dl-iscsi-eng" <dl-iscsi-eng@netapp.com>
Sent: Friday, April 25, 2003 11:08 AM
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