Re: iSCSI : target session login behaviour

[Mark Bakke <mbakke@cisco.com>]

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

--
Mark

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> 
> 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: matthewb@bri.hp.com
> 
> > -----Original Message-----
> > From: Mudaliar, Hari [mailto:Hari_Mudaliar@adaptec.com]
> > 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:santoshr@cup.hp.com]
> > 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:santoshr@cup.hp.com]
> > > 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
> >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054