No Subject

["John Hufferd" <hufferd@us.ibm.com>]

Let me see if I have everything together in the following regarding the
TSID centric assignment of ISID.

First Login:
1. Initiator contacts the target with TSID of zero, and ISID of zero
2. Target assigns the SSID by filling in the ISID and its own TSID.
3. Initiator remembers the ISID somehow.
4. If a parallel Session is establish (perhaps under a wedge driver) the
same thing will happen -- Initiator sends TSID=0 and ISID=0, except the
Target will assign a different ISID, since it is keeping state on the ISIDs
it has handed out to a specific iSCSI Initiator Node.  This will be a
different NEXUS not associated with any other session on that iSCSI
Initiator Node.
5. If a Multiple Connection per Session was established, the NON leading
connection will have the SSID (with TSID and ISID filled in), and things
will continue as currently documented.
6. If the Initiator goes down, and the parallel sessions need to
re-establish the NEXUS they come back with the TSID but may or may not have
the approprate  ISID (if they did not have a way to save it).
6a. If no ISID was used in the Initiator Login, the Target will
re-establish a new session.  The NEXUS that might have the Persistent
Reserves is still bound to the previous Session.
6b. If the New session wants to keep working with the old Persistent
Reserves, it needs explicitly blow-away the Reserves and Reclaim them (per
normal) using the Persistent Reserves Command Set.
6c. If the ISID had been saved by the Initiator, and a logon is reissued,
it can specify the ISID, and NO TSID, and the Target should then know that
a new session is starting.  The target should match the ISID with any
outstanding session it has.  That is, the Target should either match it up
the ISID with an old session (in some way), and continue, or it should Blow
the OLD session away.  David suggested a "Blow it away Bit". (This sounds
like option A and B all over again.)
6d. If the ISID was saved but it took so long that the Target's session
cleanup process, had thrown away the Old session, the Login just continues
as it does today.  The Initiator Session can not really determine if the
session continued, and it has it previous reserves, or if a new session was
created without the Reserves.  (Potential hitch.)  So the Option here is to
return an error message if there is no existing session.  The Initiator
will then need to understand this and somehow cause the reserves to be
issued again.  (Folks will say, that is what they do anyway so they will
always do that, so don't worry about it.)
(Comment:  This is now starting to get complicated again.)
7. In the case that the Initiator has "lost its way" and want to start
again,  the initiator will Login with either the current ISID, and TSID =0
or with both =0.
7a. Using the current ISID should cause the Initiator to handle it like 6c
above.  (Again, it sounds like the A, and B options).
7b. If both ISID and TSID are zero, it looks like 6a above.

OK, after looking at the above.  It seems to me that we can have this
assignment of ISID by the Target System. (It is kind of acting like a third
party ISID assigner.)  The rest of the documentation should be the same.
The issue of Option A or B is still with us. However, the issue of the
Rouge Initiator, that can not find its approprate ISID is solved. (Don't
you just love the emotive way I put that.) Also the assignment of ISIDs is
made easier for some implementations. (However, the approach suggested by
Jim Hafner seems simple enough.)

Now the discussion should be, did I miss something important, and is the
change worth it

.
.
.
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: hufferd@us.ibm.com