Subject: RE: iSCSI : target session login behaviour

From: "Mudaliar, Hari" <[email-masked]>
Date: Wed, 25 Apr 2001 16:57:17 -0700

Santosh,
	I get your point. But what if there is more than one iSCSI Host bus
adapter in a system? The Initiator Name will be the same and ISID MAY turn
out to be the same (unless the ISIDs are apportioned between the initiators
through some configuration method). This assumes that multiple sessions can
exist between one initiator system (containing multiple iSCSI off-load
engines/HBAs) and a target.

- Hari

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Wednesday, April 25, 2001 4:18 PM
To: Mudaliar, Hari
Cc: IPS Reflector
Subject: Re: iSCSI : target session login behaviour

"Mudaliar, Hari" wrote:

>         I am assuming that you are referring to the creation of a new
> session with TSID=0 in your example below. Take the case of an initiator
I1
> who has established a session with a target with an ISID=ISID1. What if a
> second initator I2 tries to login to the same target with ISID1? The
target
> cannot decide to logout the first initiator (who already has a session
> established with ISID1) as suggested by you. 

Hari,

You may want to take a second look at my mail. It specifically refers to
the problem in the context of a given (Initiator Name, ISID). Your
example above does not fall under that category. A 2nd initiator using
the same ISID would have a different Initiator Name. (a.k.a initiator
WWUI).

The problem raised is in the context of an existing session for a given
(Initiator Name, ISID). How does a target deal with a second session
login received for the same (Initiator Name, ISID) with a NULL TSID ?

>         Also, depending on implementation, the target may realize that the
> TCP connections for a session were lost (using Keep-Alives or iSCSI NOPs
> etc.) when the initiator rebooted thus terminating the session. By the
time
> a new login from the same initiator is received, the old session info may
> have been cleared.

Then again, it may not. There's 2 aspects to this issue :
1) Successful session re-logins from the rebooted host.
2) Garbage collection and cleanup of the old session resources.

(1) is a more serious issue, since the target MUST NOT reject the login
based on a pre-existing active session for a given (Initiator Name,
ISID).

(2) is handled through garbage collection algorithms, but implementation
of the proposal would help accelerate the release of stale session
resources.

- Santosh

> 
> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 11:19 AM
> To: IPS Reflector
> Subject: iSCSI : target session login behaviour
> 
> All,
> 
> How should a target respond when it receives a session login  [on a new
> TCP connection] with the same (ISID, Initiator Name) as a session
> already active at the target.
> 
> Does such a login request imply :
> 
> 1) the target should perform implicit logout and re-login of the session
> identified by (ISID, initiator name) ?
> 
> 2) Or does this result in the target responding to the session login
> with :
> a login response with status class of non-zero indicating target is
> rejecting the login ?
> 
> [The draft does not describe target behaviour for this scenario.]
> 
> iSCSI session login semantics should explicitly state that the above
> scenario will result in case (1) above. i.e. when a target sees a
> session login for a given (ISID, initiator name), it MUST treat this as
> an implicit logout of any previous session active at the target for that
> (ISID, initiator name) and then, establish a new session.
> 
> This is required because the above scenario can typically occur when an
> initiator reboots without having performed a session logout on all
> active sessions.(system did not perform an orderly shutdown).
> 
> As a side note, the iSCSI draft Status Class/Codes could do with a misc
> error category along the lines of the FC "No additional Explantion"
> reason explantion. This would help deal with error conditions that don't
> come under the listed category.
> 
> - Santosh

---

From: Santosh Rao <[email-masked]>
Date: Wed, 25 Apr 2001 17:16:08 -0700

"Mudaliar, Hari" wrote:
> through some configuration method). 

HBAs that offload session mgmt are required to accept the ISID from the
node (in this context, the host O.S. driver). This allows the node to
maintain uniqueness of the ISID within its space.

The name-disc draft explicitly states in Section    :

"The SCSI Initiator Port Name and SCSI Initiator Port  Identifier are
the iSCSI Initiator Node name together with the ISID  of the session
identifier."

<snip snip>

"There can be only one iSCSI session with a given ISID between an iSCSI
Intiator Node and an iSCSI Target Node."

<snip snip>

"There can be multiple SCSI Port objects present in an  iSCSI Storage
Node object (one for each session created). In software iSCSI
representations, the iSCSI Storage Node object creates a session process
which, in turn, represents the SCSI Port. By making the SCSI Port be a
separate object from the iSCSI Node object, it allows one to use
different combinations of software and hardware iSCSI implementations
within the same iSCSI node umbrella. Moreover, this also allows the
iSCSI Node name at the initiators to be associated with the operating
system footprint and not with any network card hardware (such as the
iSCSI offload network card). In hardware iSCSI offload card
implementations, the session process is present in the iSCSI network
card. The iSCSI Node object passes the unique iSCSI Node name and the
ISID or the TSID to the session process."

- Santosh

> This assumes that multiple sessions can

---

From: Mark Bakke <[email-masked]>
Date: Fri, 27 Apr 2001 10:16:38 -0500

Hari-

Although it looks like we didn't explicitly state this in the latest
name-disc draft, we did discuss the splitting of the ISID identifier
space amongst iSCSI HBAs.  We should add a statement like:

All entities (iSCSI HBAs, drivers, hosts in a cluster, whatever) that
share the same Initiator Name MUST coordinate the use of ISIDs amongst
themselves to avoid ISID re-use collisions.

I don't think that's quite the right wording, but anyway, I think that
this helps.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054