iSCSI: Send Targets and Report Portal Groups

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

iSCSI Team,
I would like to propose the following approaches to address the issues of
Send-Targets, and Report Portal Groups.

The way Send-Targets has evolved, which is now a separate interaction with
its own Login, makes it seem like the same function can be rationally
performed by current Discovery Functions in SLP or iSNS.  Now this is not
completely correct, but close enough for me to propose a compromise.
Before I state the compromise let me address the items that are current
concerns with an SLP or iSNS approach of replacing Send-Targets.

1. The current SLP Open Source does not do a Unicast to ask for the
information.  This is not a shortcoming of the SLP protocol, just the
current API/Implementation.  Mark Bakke has made a Hack into the Open
Source and believes that it will work just fine, and also thinks he has
support for that approach from the Owners of the Open Source.  However,
there is still some uncertainty here, which will only be cleared up with
time and multiple implementations.
2. There are separate Authentication models followed by SLP/iSNS as opposed
to iSCSI.  Therefore, any Initiator attempting to do SLP or iSNS for basic
discovery, needs to address two Authentication models, the discovery
method's authentication approach, and iSCSI's.
3. In small installations it is not clear that there will be an SLP or iSNS
setup on which to leverage this approach.

Now,  I am cretin there will be arguments about the importance of any of
those points,  the issue is -- the uncertainty of favorable results.

I am of the belief that it maybe worth the effort to move in the direction
of "atrophying" the Send Targets Command and Processes.  That is, it serves
a current and valuable function, of which a favorable replacement, though
probable, is uncertain at this time.  So we should begin moving in the
direction of the SLP/iSNS approach, but without additional care and feeding
of Send Targets.  An approach to this is to move the Send Target Command
and Processes, into an Annex of the main iSCSI protocol document.  As such
it will be a current requirement for implementation, but it will also be
clear that we believe it may be eliminated in version 2 of the iSCSI
document (when ever that occurs) and is not something in which feature
creep will be permitted.

I think the above approach will satisfy the folks that have been building
and testing various product approaches that depend on Send Targets, and yet
give them time to move to an SLP or iSNS type approach as the concerns
specified above are worked out.

It is also possible that in the future, we will find that we are
fundamentally wrong in some of our key assumptions, and that Version 2 may
move it back into the main document.  That would also be acceptable,
because I do not believe it would happen lightly, and would have to have
great reasoning and logic behind such a move.

Now, I would like to address the Report Portal Groups.  I do not place this
in the same category as Send Targets.  It is a specific query about the
environment of the specific session in which the command is issued.  It is
analogous to Report LUNs, and querying Mode Pages.

For those of you that have not been following this closely, the Report
Portal Groups, is a command that responds with the IP addresses that can be
used by the initiator of the current session, to add additional connections
to the current session (and thereby support Multiple Connections per
Session).

It is specific to its own session, and not to some general management item.
Some might say that this too could be discovered by some management
function, however, that could also be true about many of the Mode Page
setting also.  In my opinion the Portal Groups will probably be "wired in"
by the Storage Controller vendor and not be something that is settable by
the administrator.  In fact with Report Portal Groups, being part of the
base protocol, the SLP/iSNS (or the Send Targets Command)  will not have to
include the portal group identification/tagging in its responses, thus
simplifying them.

So as part of my proposed compromise I recommend that we put "Report Portal
Groups" into the main iSCSI Protocol Document, like any of the other iSCSI
Commands, and move the Send-Targets command to an Annex as specified above.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com