Subject: RE: iSCSI : target session login behaviour

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Thu, 26 Apr 2001 10:47:17 +0100

Hari,

In response to your email

Either:

The two HBAs are operating independantly (i.e. sessions do not span HBAs)
and therefore should have some form of differentiation: e.g. a different
iSCSI Initiator name, or they do need to have some form of co-operatation at
the iSCSI layer(s)/configuration to ensure uniqueness of the ISID as you
have suggested.

Or:

The two HBAs are operating together (sessions can span HBAs) in which case
there is effectively only one iSCSI Layer and so the ISID will be different
when the initiator creates a new independant session, or the ISID and TSID
is the same and the initiator is creating a new connection within the same
session albeit on a different HBA.

Matthew Burbridge
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

> -----Original Message-----
> From: Mudaliar, Hari [mailto:[email-masked]]
> Sent: 26 April 2001 00:57
> To: 'Santosh Rao'; Mudaliar, Hari
> Cc: IPS Reflector
> Subject: RE: iSCSI : target session login behaviour
> 
> 
> 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: Thu, 26 Apr 2001 10:55:03 -0700

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> iSCSI Initiator name, 

One would hope that such mis-abuse of the Initiator Name (WWUI) is not
repeated as was done with the FC Node WWN. The Initiator & Target Names
(WWUI) are explicitly defined in the name-disc draft as :

"The terms "initiator name" and "target name", when used in this
document, refer to iSCSI Node Names."

<snip snip>

"The Initiator Name corresponds to the logical operating system on which
the initiator is running, and the Target Name corresponds to the target
Storage Node entity."

<snip snip>

"An iSCSI Name really names a logical software entity, and is not tied
to a port or other hardware that can be changed.  For instance, an
Initiator Name should name the iSCSI initiator driver, and not a
particular NIC or HBA card.  When multiple NICs are used, they should
generally all present the same iSCSI Initiator Name to the targets,
since they are really to the same entity.  In most operating systems,
the named entity is the operating system image.  Most hosts will have a
single OS running; some of the really big ones could have multiples. 

A target name should similarly not be tied to hardware interfaces that
can be changed.  A Target Name should identify the logical  target,and
must be the same for the target regardless of the physical porton which
it is addressed.  This gives iSCSI initiators an easy way to determine
that two targets it has discovered are really two paths to the same
target." 

The wording above should be strengthened from "should" to "MUST".
Failure to do so could result in the same mis-abuse as has occured with
FC Node WWNs.

Ex : 
"For instance, an Initiator Name MUST name the iSCSI initiator driver,
and not a particular NIC or HBA card."

"When multiple NICs are used, they MUST present the same iSCSI Initiator
Name to the targets, since they are really to the same entity."

- Santosh

---

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

Correct.  We had intended this behavior in the name-disc draft,
and will add it next time.

--
Mark

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