Subject: Re: iSCSI: ISIDs

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 02:17:28 -0700

David said:
"Recoverable session resources would be associated with the combination
of <iSCSI Initiator Name, TSID> at the iSCSI Target, and the initiator
tracks via <iSCSI Target Name, TSID> - in both cases the TSID replaces
the ISID."

Jim, & David, please correct me  but I think this means that only one
Session could be started from any iSCSI Initiator Node to a Given Target.
We previously permitted multiple sessions, since a number of vendors
thought Single Connections pre session was simpler to implement and did not
want to implement Multiple Connections per Session.  They were going to
continue (as they did in Fibre Channel) to rely on the "Wedge" driver
approach.

Now the Wedge Driver has not really a been defined as an SCSI construct, it
just does a job that has been needed in connections like Fibre Channel.
The ISID is what permits this case (of multiple individual connection
sessions) to operate while sharing the same authentication space (iSCSI
Node Name) with the other Sessions connected from the same Host to the same
iSCSI Target Node.

Many of us thought that Multiple Connections per Session was a better
approach, but still a number of vendors saw simplicity in Single
Connections per Session.  The implication of that is they need the ability
to bring multiple of these single sessions together via a Wedge Driver. And
hence the need for ISID.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

[email-masked]@ece.cmu.edu on 09/06/2001 02:40:19 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  iSCSI: ISIDs

Time to back up and regroup on this topic.  It's clear that ISID
management needs more attention, and hence there are some issues
more basic than the attempted consensus call to work out.  So,
I'm going to abandon the attempted consensus call, and try to
make progress on the underlying ISID issue.  Those whose posts
have called ISID management into question should not feel it
necessary to apologize - this is an important issue to unscramble.

A rough summary of where we find ourselves is:
- iSCSI Initiator Names span network interfaces/adapters,
     as do iSCSI Target Names.
- Multiple sessions are allowed between an iSCSI Initiator
     and Target.  These are identified by an ISID and a
     TSID.
- The ISID is the Initiator portion of the Session identifier
     and is used to track certain resources associated with
     the session (e.g., persistent reserves).
- The TSID is the Target portion of the Session identifier,
     and serves primarily to make sure that all session
     identifiers (SSID = ISID||TSID) are unique at the
     Target.

Michael Schoberg suggest getting rid of the ISID:

> ISID - initiator-defined session-identifier
>
> Since initiators don't know about other initiators connected to this
target,
> this has the potential of causing problems.  Eliminate it.  The initiator
> should simply state it's intentions of establishing a new session or
adding
> a connection to an existing session (via binary flags).

The implication of this would be to make SSID = TSID, dynamically
assigned by the Target (0 is a reserved value on Login asking Target
to do this assignment), and partitioned appropriately across interfaces.
Recoverable session resources would be associated with the combination
of <iSCSI Initiator Name, TSID> at the iSCSI Target, and the initiator
tracks via <iSCSI Target Name, TSID> - in both cases the TSID replaces
the ISID.  From a functional standpoint, this looks like it works,
and has the nice additional property that session resources can be
recovered through any iSCSI Initiator interface vs. having to go back
to the one that's allowed to use the ISID for that session if ISIDs
are statically partitioned.

Does this cause any problems for the SAM-2 to iSCSI mapping?

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Fri, 7 Sep 2001 09:29:46 -0400

> Session could be started from any iSCSI Initiator Node to a Given Target.

No, multiple sessions are still possible - they'd be distinguished by
different TSIDs.  If different portal groups are in use, that'd have
to be encoded in the TSID.

--David

---

From: JP Raghavendra Rao <[email-masked]>
Date: Fri, 7 Sep 2001 07:31:33 -0700 (PDT)

If an interface/adapter is sharing Initiator Name with other
interfaces/adapters, iSCSI *REQUIRES* that there be a higher
level "session manager" (in the OS) to manage various things
like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't
understand why ISID assignment can not be managed by the
same "session manager". How is ISID assignment a unique problem
compared to the rest of various shared session level parameters ?

If an interface has a unique Initiator Name, it can assign
an ISID of its own.

-JP

---

From: [email-masked]
Date: Fri, 7 Sep 2001 10:49:27 -0400

> same "session manager".

That's not exactly true.  There are two sorts of coordination that
can be necessary if an Initiator Name spans interfaces/adapters:

(1) Task Tags, Sequence Numbers, ExpStatSN, etc. WHEN an individual
	session spans interfaces/adapters.  The set of spannable
	interfaces/adapters is called a "portal group".
(2) ISID assignment to different sessions in the same or different
	portal groups.

> How is ISID assignment a unique problem

Because ISID assignment is a separate problem.  One still has to
coordinate ISID assignment across interfaces/adapters even if
*every* session has exactly one connection and hence can't span
interfaces/adapters.

> If an interface has a unique Initiator Name, it can assign

Right, but if every interface is its own portal group underneath
the same Initiator Name (i.e., sessions don't span interfaces,
but the iSCSI Initiator does), ISID assignment still has to be
coordinated across interfaces/adapters even though there's no
"session manager" needed across interfaces/adapters.

Thanks,
--David

> -----Original Message-----
> From: JP Raghavendra Rao [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 10:32 AM
> To: [email-masked]
> Subject: Re: iSCSI: ISIDs
> 
> 
>

---

From: "Jim Hafner" <[email-masked]>
Date: Fri, 7 Sep 2001 08:46:35 -0700

David,

I've been mulling over your question concerning how Michael's proposal
(which I read as removing the ISID from the SSID and leaving it up to the
target to assign the SSID) affects the SAM-2 mapping.  I don't have a good
answer.  So, I'm going to brain dump here.

We have (so far) relied on the ISID (along with the iSCSI Name) for the
SCSI Initiator Port name (and identifier) and relied on the "iSCSI
initiator endpoint of the session" for the SCSI Initiator Port.  The ISID
RULE (no reuse of ISID to a given target portal group -- and whose
enforcement rule we've been debating) was intended to prevent parallel
nexus from being created.

If we abandon any notion of the initiator providing the ISID then we've
somehow lost our handle on what constitutes the SCSI Initiator Port.  We
effectively have to go back to square one to sort out the initiator side of
the model mapping.  I think we all pretty much agree that the iSCSI Node
and the SCSI Device are intimately bound together.  Our choice for SCSI
Initiator Port come down to three
possibilities (as they always have):

a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI)
-ported.  Then the SCSI Initiator Port can be identified by the iSCSI Name.
There are similarities between this and a single ported FC HBA.  Our
problem is then the parallel nexus issue.  We need a rule that says that we
can't have more than one session between a given iSCSI Initiator and iSCSI
Target Portal Group; and we need to define the target's response to a
second such login.  In effect, we've doubled our problems.  We have limited
our connectivity possibilities between a given iSCSI Initiator (max
sessions = number of target portal groups) and we still have a 'rejection'
rule to decide (option A or option B).

b) use the model we have for the target; namely, map the iSCSI Initiator
Portal Group to a SCSI Initiator Port.  With this, we get a SCSI Initiator
Port name equal to the iSCSI Name + portal group tag. So far so good.  But
we are limited to one session per (initiator portal group, target portal
group tag).  This has similarities to a multi-HBA FC host.  We again limit
(to a lesser extent) our
connectivity possibilities: max sessions = (number of initiator portal
groups x number of target port groups).   [In spite of the simplicity of
this model which is independent of session identifiers, I didn't pick this
because people felt that there was a legitimate reason to build multiple
sessions between two portal groups (e.g., in the case where both initiator
and target have only one HBA (so one portal group) and the target doesn't
support more than one connection per session, I may want to build multiple
sessions for extra parallelism, etc.).]

c) use the model we now use (SCSI Initiator Port = initiator end of
session) but find something other than the ISID to define the SCSI Port
Name.  The only choice seems to be the SSID (=TSID).  This might work more
or less as David outlined.  It's a little odd, however, that the target is
now *assigning* an identifier/name to the SCSI Initiator Port; that is, the
SCSI Initiator Port doesn't have a name 'all to itself', but only in the
context of a target.  The mind sort of boggles with this (and it certain
stretches the credibility of the SAM-2 model of SCSI Initiator Port, Port
Name and Port Identifier). We could instead pick for the SCSI Initiator
Port Name/identifier the
union of the ipaddresses:tcpports of all the connections involved in that
session, but I don't think that really gains us anything.

In short, I don't know what approach to take here.

We are effectively being constrained by SAM-2's model.  We've already
stretched that model a lot by what's currently in the draft. Summarizing
above, we can either limit our functionality (fewer sessions) or stretch
the model further by having the target assign names to SCSI Initiator
Ports.

It's not a good place to be.

Jim Hafner

[email-masked]@ece.cmu.edu on 09/06/2001 02:40:19 pm

To:   [email-masked]
cc:
Subject:  iSCSI: ISIDs

target,
adding

Thanks,
--David

---

From: JP Raghavendra Rao <[email-masked]>
Date: Fri, 7 Sep 2001 08:16:40 -0700 (PDT)

I guess I screwed up what I wanted to say in my previous
posting. I was trying to compare ISID assignment problem
with "session management" with regard to the need for an
independent, OS level management entity. We need an in-kernel
"session manager" to manage sessions spanning interfaces/adapters.
And why can not a similar manager (call it "isid manager")
exist if an interface/adapter is to share Initiator name ?

I understand that not all operating systems would ship
with these OS level "resource managers" in the nearest
possible future - what this means is that you can not
share Initiator Name if no such "isid manager" exists
at the OS level. Isn't the same true for "session manager" ?

-JP

---

From: [email-masked]
Date: Fri, 7 Sep 2001 12:06:29 -0400

> at the OS level. Isn't the same true for "session manager" ?

No - if one is prepared to treat every interface/adapter
as a separate portal group (i.e., an individual session uses
only one interface/adapter), one can share the Initiator
Name without the need for a "session manager", but the
"isid manager" would still be needed to manage ISIDs across
the interfaces/adapters.

Thanks,
--David

> Sent: Friday, September 07, 2001 11:17 AM
> To: [email-masked]
> Subject: RE: iSCSI: ISIDs
> 
> 
> 
> > > > > this has the potential of causing problems.  
> Eliminate it.  The 
> > > initiator

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 09:22:51 -0700

David,
Your reply is not clear.  Please explain how the TSID would be formed in
the parallel session mode on the initiator (with a Wedge Driver in use)?
Then how would the session be cleaned up on reboot?
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

[email-masked] on 09/07/2001 06:29:46 AM

To:   John Hufferd/San Jose/IBM@IBMUS, [email-masked], Jim
      Hafner/Almaden/IBM@IBMUS
cc:   [email-masked]
Subject:  RE: iSCSI: ISIDs

--David

---

From: Michael Schoberg <[email-masked]>
Date: Fri, 7 Sep 2001 11:49:17 -0500

Ultimately, the detection of duplicate sessions has to occur on the target.
If we are not expecting initiators to retain the TSID (target assigned SID)
of any sort between reboots, then something totally initiator based may be
the only fit.  The recurring theme here is how to authenticate the passed
ISID & TSID.  What prevents HBA-B from saying it's HBA-A (or however you
want to word it)?  Putting session identification into the authentication
exchange (and NOT the login header) may be the only way to guarantee
detecting imposters.  If you want to guarantee security along with recovery,
I think this would be the better place to begin.

It appears as though SID needs to act more like the Ethernet MAC address.
We want something that uniquely identifies the initiator whenever it logs
into a target (something larger than 16 bits).  This moves more towards
Marjorie's position that session identification should be pre-assigned to
initiators through configuration:

	... an iSCSI HBA will have to have a configuration interface,
	supplied by the manufacturer, in order to be installed ...

I'm a little skeptical about the dual use of InitiatorName as part of the
session identification.  What prevents a pool of servers from sharing the
same user account credentials (which may be useful in reducing
administration overhead).  It's unlikely that a group of servers would ever
want to share the same session.  Something like "SessionId=" that is
pre-configured on each initiator might work better.

---

From: [email-masked]
Date: Fri, 7 Sep 2001 12:53:58 -0400

John,

> the parallel session mode on the initiator (with a Wedge Driver in use)?

Reserved TSID value of 0 (meaning "Please allocate a TSID") is sent on
each leading login.  Target allocates different TSIDs to the different
parallel sessions.  Wedge driver continues to work as it always has.
A separate reply is coming to Jim's concern about how to map the
"SCSI Initiator Port" concept, and will address the concern that the
wrong mapping could limit the number of parallel sessions.

> Then how would the session be cleaned up on reboot?

A login with a non-zero TSID references the existing session with that
TSID.  A login with a zero TSID always creates a new session.  If the
Initiator has forgotten the TSID, the Target garbage collects that
session using the same sort of timeout approach that it uses to recover
from Initiators who have crashed and gone away.  As noted earlier, if
there are session resources like a Persistent Reserve on a session for
which the Initiator has forgotten the TSID, the Initiator has a problem
no matter what (same thing happens with current spec if it forgets the
ISID).  If we want the "Option A" functionality to aggressively
blow away the old session, we'd probably have to add a bit to login
saying "destroy the old session with this TSID (after checking that the
authentication matches)" in order to distinguish the "error recovery"
vs. "expedited destruction of old session" scenarios.

Target implementers probably need to be strongly advised that they
SHOULD NOT aggressively reuse session identifiers (e.g., TSIDs
can be allocated off of a counter that rolls over back to 1 from
its maximum value, along with a check for duplicates) to reduce
problems that could arise from "expedited destruction" if the
Target has reused the TSID value for a different session to the
same iSCSI Initiator.

Thanks,
--David

> From: John Hufferd [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 12:23 PM
> To: [email-masked]
> Cc: Jim Hafner; [email-masked]

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 10:50:27 -0700

During various meetings that we had as part of the Naming and Discovery
Team,  there was desire to have the same iSCSI Node Name  be used across
the Cluster, since it functions as a single logical OS.  It was thought
that the Cluster would then use static allocation to assign the ISID ranges
to the various members.

In this way the Cluster would have one Authentication Name (iSCSI Node
Name).  So the model we have today does extend across a Cluster.

Based on what I have seen on this thread, that approach (Sharing the iSCSI
Node Name across the Cluster, as a single  logical OS) still works even
with the TSID centric approach.

.
.
.
John L. Hufferd

Michael Schoberg <[email-masked]>@ece.cmu.edu on 09/07/2001
09:49:17 AM

To:   [email-masked]
cc:

detecting imposters.  If you want to guarantee security along with
recovery,

---

From: [email-masked]
Date: Fri, 7 Sep 2001 13:48:22 -0400

> somehow lost our handle on what constitutes the SCSI 
> Initiator Port.

Let me take a whack at preserving something approximating the existing
situation.  Starting from your option c):

> context of a target.

Do we actually need an externally visible identifier for the SCSI
Initiator Port?  There's clearly a session endpoint on the Initiator
side that corresponds to the <iSCSI Initiator Name, ISID>, and the
implementation is clearly able to identify it internally to keep its
sessions straight, and this identification will be (at least implicitly)
visible through a management interface that looks at all the open sessions
on a host or device.  In essence, I'm suggesting keeping the current
mapping, but allowing part of the endpoint identifier to not be
visible in the protocol.

--David

> From: Jim Hafner [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 11:47 AM
> To: [email-masked]

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 11:59:58 -0700

Jim,
I am NOT at this time advocating the TSID centric view.  However, I am not
sure that our iSCSI to SCSI Mapping is a problem even if we use a TSID
centric view.  In other words, the Session is Not established until you
finish the Login.  Also, we have the Software Scenario that dynamically
creates its SCSI Port, so having the software and the HW define themselves
at the completion of the Login should not be a problem either.  Am I
missing something important here.

David, I am not sure exactly what you were saying, I think it is similar to
what I said.

.
.
.
John L. Hufferd

[email-masked]@ece.cmu.edu on 09/07/2001 10:48:22 AM

To:   Jim Hafner/Almaden/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: ISIDs

--David

> Initiator Port.  We

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 7 Sep 2001 12:37:45 -0700

I overlooked putting the IPS group on my note to David, so let me re-post
it with David's reply.

David,
First, it is not clear that you do not come up with others problems, a full
circle tends to do that.

I do not see any reason for changing, in the protocol spec., the layout of
the TSID.  This kind of sounds like an implementation.

.
.
.
John L. Hufferd

[email-masked] on 09/07/2001 11:56:06 AM

To:   John Hufferd/San Jose/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: ISIDs

With the important difference that all of Nick's scenarios in
which ISID mismanagement causes disasters are gone, along with
any need for a cross portal-group "isid manager".  I'll take
this sort of simplification and increase in resistance to mistakes
any day.  Next step will be to divide the 32-bit TSID into an
8 bit target portal group and 24 bit ID within portal so that
there's no confusion about where to go to deal with a session.

--David

> Sent: Friday, September 07, 2001 2:26 PM
> To: [email-masked]
> David Said:
> "If we want the "Option A" functionality to aggressively
> vs. "expedited destruction of old session" scenarios."
>
> The use of this "blow away" bit sounds similar to option B.
> This seems to
> bring us full circle.
>
> And the only thing that we solved is how to hand out ISIDs
> (by not doing
> it).
>
>
> .
> .
> .
> John L. Hufferd

---

From: "Jim Hafner" <[email-masked]>
Date: Fri, 7 Sep 2001 15:04:17 -0700

David,

Two points.

1) I think there's some confusion on what Michael's suggestion really is.
Some seem to think that the idea *replace* the SSID=ISID||TSID with just a
32bit TSID (so there is no ISID component at all).  The other is that the
target provides SSID but it is still viewed as two components (and each
component has some role to play).
Can we get this clarified?  I was under the assumption that it's the first
option here.

Your note about 32bit TSID of which part of the name was the portal group
tag made me think that you're in the first camp.   But your comment below
about <InitiatorName,ISID> makes me think you're in the second camp.

  >mapping, but allowing part of the endpoint identifier to not be
Where is the ISID coming from (see the question above)?  What part of the
endpoint identifier is NOT visibile?  There are lots of ways for an
implementation to identify internally it's sessions, and need not at all
rely on any part of the SSID (e.g., my connection structure contains a
pointer to an open socket and a pointer to a session structure, so any
message on that socket must be related to that session).   The point being
that my implementation doesn't have to care at all about SSID.

Nobody has really asked for an 'externally visible identifier' for the SCSI
Initiator Port (at least I don't think I have directly).  What I'm looking
for is the thing the SCSI device server (implicitly) uses to identify the
"I" in the I_T nexus.  Up till now, SCSI/SAM has had a static hardware
identifier for that thing (parallel bus address, the FC nodename, etc.)
because there was a hardware component on which to bind the SCSI Initiator
Port.  So, that name/identifier was an inherent component of the SCSI
Initiator Port implementation that was propogated *from the intiator side
to the target side* in protocol specific ways.  My model(c) and what I
think you're suggesting says that we're allowing the iSCSI target to pass
to the iSCSI initiator the 'name' that the constructed SCSI Initiator Port
will/shall/must use.    So, the naming authority is not on the initiator
side and the name doesn't flow from the initiator to the target, but is
reversed in both cases.

It's not "my name is Bob!", it's "who do you want *me* to be today?" (to
paraphrase Oingo-Boingo).

So, what I said was that this 'might work' but I think it stretches the SAM
model in ways that haven't been explored yet.
A property of the just defined (by T10) SCSI Port Name is that it is (a)
world wide unique (within the protocol) AND (b) that it is persistent.  So,
if two different iSCSI targets choose the same TSID=SSID for their sessions
with a given iSCSI initiator, they have both 'implicitly' connected to the
same 'I' in the I_T1, I_T2 nexus.  Does that make sense?

Also, it means that for all possible TSID=SSIDs there is an implicit
(sleeping) SCSI Initiator Port waiting to be awoken.  That's also true in
the current model with ISID generated by the initiator, however, the
difference is that the initiator wakes up the sleeping SCSI Port by first
use of the ISID value in the login.  In this new approach, the port isn't
woken up until the target sends back the TSID (in effect, the TSID in the
response can be viewed as a 'request to wake up that partial SCSI Initiator
Port').

As I said, it might work, but it certainly has odd implications.  I'm more
comfortable with the current model (and I think all the ISID partitioning
issues are just a matter of convention), however, I don't have (as I said)
a strong argument against the new one.  It just "feels funny".

Jim Hafner

[email-masked] on 09/07/2001 10:48:22 am

--David

---

From: [email-masked]
Date: Fri, 7 Sep 2001 18:41:43 -0400

Jim,

> about <InitiatorName,ISID> makes me think you're in the second camp.

I'm in the first camp.  The "<InitiatorName,ISID>" text was meant
to refer to the current situation in which that pair is the
visible identity of the SCSI Initiator Port.

> endpoint identifier is NOT visible?

The ISID goes away, and what replaces it could be the TSID
(which you have problems with) or something internal to
the Initiator implementation ...

> There are lots of ways for an implementation to identify internally it's
> sessions, and need  not at all rely on any part of the SSID (e.g., my
> connection structure contains a pointer to an open socket and a pointer
> to a session structure, so any message on that socket must be related to
> that session).   The point being that my implementation doesn't have to
> care at all about SSID.

Yes, use something like that as the identifier for the session endpoint
that gets mapped to the iSCSI Initiator Port.

> "I" in the I_T nexus.

Good, that was the answer I was hoping for.

> Up till now, SCSI/SAM has had a static hardware

Actually I'm suggesting something different.  The Initiator implementation
knows that it wants to create a session to the Target, and has a notion
of that session when it sends the Login - this is well before
the target has assigned a TSID.  In essence, that internal notion of
session is an implicit naming authority that avoids the concern about
the iSCSI Initiator Port obtaining its identity from the Target - in
essence the iSCSI Initiator Port has to exist in order to send the Login
to the Target, and hence has a notion of identity independent of the
Target to which it wants to connect because the iSCSI Initiator Port
exists prior to establishment of that connection or assignment of
the TSID to the session.

[... Rest snipped, as I departed from your assumptions in the above
 paragraph ...]

Thanks,
--David

---

From: "Jim Hafner" <[email-masked]>
Date: Fri, 7 Sep 2001 16:37:42 -0700

David,

OK, I see where you're going.  The SCSI Initiator Port is created by the
initiator side and has an identity defined internal to that implementation
(say, the pointer to the session structure).  What the target's device
server uses is the 'identifier' the iSCSI layer assigns to that SCSI
Initiator Port, namely the <initiator Name, TSID>.

Let's see where this goes.
First, it means we don't really have "name" (as defined by SCSI/SAM) for
the SCSI initiator Port, but we do have well-defined "port identifier" (the
device server's identifier mentioned above).  I read SAM as saying that the
name is an intrinsic property of the SCSI Initiator Port.  So, we don't
have a name because haven't associated an intrinsic property.

Now, SCSI has two notions, port identifier (think FC S_ID, as an address)
and port name (think FC WWportname).  The current wording of SCSI says that
it's the port identifier that is the thing that identifies the owner of a
reservation (e.g.) [in the context of a given SCSI target port].  There's
extra language to deal with the identifier for a given named port changing
by events in the service delivery subsystem (think FC network
reconfiguration).    Proposed new text would make this more clear.  The
named port would own the reservation independent of identifier, *provided*
a name was available for the initiator port.

So, where we're going here is that for iSCSI, there would be no name for
the SCSI initiator port, just the identifier (as assigned by the target).
So long as the target was happy with the association of that identifier
with the SCSI initiator port (that it didn't think the identifier somehow
moved to a different actual SCSI initiator port), then recovery of state
would be as you suggest -- the initiator just re-establishes the session by
requesting the SSID=TSID.

It's an open question that if the session collapses or even is politely
logged out, whether the TSID identifier and all the resources associated
with it are cleared or not.  I would guess not, but I'm not sure.  Also,
there's cleanup issues on TSID (when does the target decide it can recycle
a TSID?  when there are no persistent state to track for it?).

So far so good, I think.

Now comes a slight kicker!  There is proposed language for SCSI that would
allow a device server to associate a reservation with a SCSI initiator port
*independent of the SCSI target port*, so I could have a path from one SCSI
Initiator port through each SCSI target port and the reservation state
would be equivalent over all the paths (sort of I_*_L nexus).  This new
language is based on one fundamental principle, that is, that the SCSI
initiator port has a world wide unique persistent intrinsic NAME on which
to base the unambiguous recognition of that SCSI Initiator Port independent
of the target port.  In other words, with a name, the device server can
recognize the same initiator port through any of its target ports and so
grant equivalent access rights.   Remove the name from iSCSI's SCSI
Initiator Port (which you are effectively doing no matter how you look at
it), and you can not take advantage of this proposal's new functionality.

This is the kind of functionality that many people not intimate with SCSI
assumed was already there (and in fact there were assumptions that
reservations went so far as to span initiator ports).   Unfortunately,
that's not the model in SCSI. This pending proposal is an attempt to get to
that functionality defined within the parameters defined by SAM-2.

Note that with the initiator generated ISID as part of the SCSI Initiator
Port Name (it's intrinsic), we had the ability to reuse that same ISID for
each target portal group (without problem) and get this equivalent
reservation state across all those target portal groups (aka, SCSI Target
Ports).

I don't know if that is too much of a monkey wrench in the works, but it
bothers me some.

Jim Hafner

[email-masked] on 09/07/2001 03:41:43 pm

Jim,

Thanks,
--David

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 8 Sep 2001 11:11:11 +0300

Besides having the initiator remember the TSID the target will have to know
when it can reuse a TSID.
Although rather academic this is bound to cause problems as different parts
of the target stack are in charge
with reservations, port assignment etc. - and targets go through reboots
too.

The original intent of having the two parties each contribute a part over
which it has exclusive control
and generate together a "unique" sessionID was meant to solve both the
unique allocation and reuse issue
and splitting the space over several adapters did not seem a big price to
pay.

Julo

[email-masked]@ece.cmu.edu on 07-09-2001 16:48:17

Please respond to [email-masked]

To:   [email-masked], [email-masked]
cc:
Subject:  RE: iSCSI: ISIDs

Rod,

>    I don't see how having the target assign the ISID, and effectively
> the whole SSID helps with the original problem of recovery from an
> uncontrolled restart. In fact, I think it makes it worse.

It helps with the following problem:

     When the initiating adapter/interface assigns the ISID, mistakes
     in assigning the ISID (inadvertently using the same ISID twice
     on two different interfaces) can cause sessions to step on each
     other when that was not the intended result.  If there's no
     ISID, and TSID is dynamically assigned by the Target, this
     problem can't happen.

Recovery from an uncontrolled restart wouldn't change in principle.
In order to recover session resources (e.g., persistent reserves), the
HBA had to remember the ISID - now it would have to remember the TSID.
In practice, this may be an important difference - an HBA can "remember"
the ISID(s) by always using the same ISID value(s), whereas the TSID(s)
have to be stored after being provided by the target.

>    Without and initiator assigned ISID the target is presented with no
> information with which to distinguish HBAs in a host. Assuming that
> HBA 1 has an existing session, how can the target tell the difference
> between HBA 2 sending a leading login with the intent of starting a
> new session, and HBA 1 sending a leading login after an uncontrolled
> restart?

HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the session it's
trying to recover.  Two HBAs are not necessary to create this scenario -
it can occur with two sessions on a single HBA.  If the HBA has forgotten
the identity of the session it's trying to recover, that session is
unrecoverable, but see above comment on differences in remembering
an ISID vs. a TSID.

Thanks,
--David

> From: Rod Harrison [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 5:34 AM
> To: [email-masked]; [email-masked]
>    I don't see how having the target assign the ISID, and effectively
> the whole SSID helps with the original problem of recovery from an
> uncontrolled restart. In fact, I think it makes it worse.
>
>    Without and initiator assigned ISID the target is
> presented with no
> information with which to distinguish HBAs in a host. Assuming that
> HBA 1 has an existing session, how can the target tell the difference
> between HBA 2 sending a leading login with the intent of starting a
> new session, and HBA 1 sending a leading login after an uncontrolled
> restart?
>
>    - Rod
>
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, September 06, 2001 10:40 PM
> To: [email-masked]
> Subject: iSCSI: ISIDs
>
>

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 8 Sep 2001 11:37:57 +0300

There is no logical difference between the current split allocation scheme
and having only the target allocate it
(a port could be associated with anything) and the initiator could remember
a SSID as well as a ISID.

The major difference is "control". In the current scheme the initiator and
target could independently allocate and reuse their parts.

The target allocates only scheme leaves this to the target (it has to do
garbage collection) under the assumption that the target (unlike the
initiator) has a central point of control.

Aren't targets going to have several HBA and have to carefully allocate
their SSIDs?

In the event an initiator wants to rebuild a session does he have to
connect to the same HBA and thus a failover to another HBA can't be done.

For all the above no to happen we have to add some management somewhere and
it looks to me that the current scheme is simpler than a target centric one
as it keeps the allocation and release of numbers at the same end.

Julo

[email-masked]@ece.cmu.edu on 07-09-2001 20:48:22

--David

---

From: [email-masked]
Date: Mon, 10 Sep 2001 02:16:39 -0400

One more whack at this ...

> initiator) has a central point of control.

Yes, I'm assuming that targets will have a single vendor in charge
of all the software on the target and making it work right if there are
multiple HBAs; I don't see any corresponding vendor who's in a position
to do the same for the initiator ...

> Aren't targets going to have several HBA and have to carefully allocate

But they'll have one vendor in charge of making this work.  In contrast,
for an initiator with HBAs from two different vendors, both of those
vendors and the vendor of the OS platform have to be involved, and I
don't see any of them taking full responsibility in the early going.
I'm worried we risk heading the iSCSI Initiator Name down the same
path as Fibre Channel, where the FC Node WWN was supposed to be associated
with the server into which the HBAs were plugged, but got associated
with the HBA because there was no way to coordinate across HBAs.
If anything ever goes wrong with ISIDs (and things will), the fastest
way to fix it will be to require each HBA to have its own iSCSI Initiator
Name, independent of the intent of the iSCSI naming architecture.

> connect to the same HBA and thus a failover to another HBA 

No, this is controlled by portal groups.  To failover across two HBAs
on the target, they have to be in the same portal group, and the target
is responsible for coordinating TSID usage within each portal group.
If the target can't coordinate TSID usage, it puts the HBAs into different
portal groups and gives up this failover ability as a consequence, and
that's the case independent of whether ISIDs exist or not.

> as it keeps the allocation and release of numbers at the same end.

I'm sorry, that doesn't parse for me.  It looks like the same sort of
mechanism is being put into both initiators and targets for symmetry,
without considering whether two instances of the mechanism are actually
necessary.  In a target-centric scheme, the target is doing the "allocation
and release" of numbers.  The target does have to be careful about not
aggressively reusing TSID values, when there's potentially recoverable
state around (or the initiators may think that there's state to be
recovered even though the target's lost it all in a reboot), but recall
that aggressive reuse of ISIDs is what created the Option A/B/C mess
(and not aggressively reusing ISIDs would make that easier to solve).
I don't understand how two instances of similar mechanisms is "simpler"
than one.

--David

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 10 Sep 2001 12:05:33 +0300

David,

This relatively complicated and hard to discuss on the mailing list. During
a flight I made a summaryY.
allocating to vendors is not a good idea and failover of an entire session
should be possible between portl groups.

Portal groups are meant to delimit connections that cooperate within a
session.

If a session on PGa goes away you may want to reinstate a session on PG b
ineriting the same properties.

There is nothing to prevent you now to do it (and that is good). The ID
splitting can get a bit skewed.

The same will happend whatever sheme you choose and vendors certianly don't
have to get involved.

Julo

[email-masked] on 10-09-2001 09:16:39

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI: ISIDs

--David

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 10 Sep 2001 08:35:10 -0700

Julo,

Unfortunately, the way things are modeled now, it is impossible to recreate
a session on a different target portal group and inherit all the same
properties.  The reason is that at least some of the properties are bound
to the I_T nexus and the "T" is the portal group.  If you request a change
to a different portal group, you've changed the "T" and so an equivalent
nexus cannot be built.

With what we have today, I can claim to a different target portal group
that I'm the same "I" in a previous I_T nexus, but that's about all.  (And
there-in lies the root of the "reservations kicker"!).

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 09/10/2001 02:05:33 am

To:   [email-masked]
cc:

David,

Julo

--David

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 10 Sep 2001 08:38:50 -0700

David and Julian

On second thought, let me qualify what I just said in my last posting about
recreating the session on a different portal group.

As far as the model is concerned, that still holds, BUT it doesn't prevent
failover from one HBA to another!  The reason is that all of the properties
of the failed HBA can be assumed by the back up HBA (this includes,
ipaddresses, portal group tag, etc.).  So, phyically, the HBA may be a
different one, but the model view of the portal group is still the same
(different hw, same 'identity').   Similar things happen with just IP
addressing today and with FC functions as well.

Jim Hafner

[email-masked]@ece.cmu.edu on 09/09/2001 11:16:39 pm

--David

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Sep 2001 11:14:34 +0300

Jim,

For reason that must be evident by now we are then attacking the wrong
issue.
Multi HBA targets are/will be common and not I was under the impression
that the persistent items are related to the initiator-name+ISID (the draft
states it in more than one place) and we can recapture them at any target
port.
If that is not so HA will have another hurdle to handle and an ugly one at
that.

My impression when reading the model was that portal groups are (the
physical entity) are there to let us know which HBA elements are there that
are willing to coordinate between then things that have to be coordinated
within a session and that the target will create  an I_T nexus that
logically inherits everything based on IName+ISID regardless of the TSID it
assigns for local uniqueness.

As an I_T nexus is a logical entity we can still map it to a session and
the SAM model is preserved.

Julo

Jim Hafner@IBMUS
10-09-2001 18:35

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
From: Jim Hafner/Almaden/IBM@IBMUS
Subject:  RE: iSCSI: ISIDs  (Document link: Julian Satran - Mail)

Julo,

Jim Hafner

To:   [email-masked]
cc:

David,

Julo

--David

---

From: "Jim Hafner" <[email-masked]>
Date: Tue, 11 Sep 2001 08:38:50 -0700

Julo,

I think you're interpretation isn't quite correct (at least as I've
proposed the model).  Your definition of the Target Portal Groups is
correct with respect to the iSCSI model except that they are not
necessarily physical entities - e.g., I could have one or more target
portal groups which are strictly software constructs.  In the mapping to
SAM-2, the Target Portal Groups are associated to the SCSI target ports and
an I_T nexus then must have a relationship to a named Target Portal Group
(the T).  It only be "recreated" with the same "I" and the same "T".
However, as I indicated in the other note, Target Portal Groups are still
only logical entities (as are the nics that hold ipaddresses).   So, the
tight relationship to a physical component need not be rigid and
fundamentally, the recovery you want is possible, though it isn't trivial.

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 09/11/2001 01:14:34 am

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   "ips" <[email-masked]>
Subject:  RE: iSCSI: ISIDs

Jim,

Julo

Jim Hafner@IBMUS
10-09-2001 18:35

Julo,

Jim Hafner

To:   [email-masked]
cc:

David,

Julo

--David