[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