Re: iSCSI login phasing

[Michael Schoberg <michael_schoberg@cnt.com>]

The 13 x 13 login state chart and the state diagrams may confuse some people
out there (including me).  Because of all the transactions that need to take
place, I don't think you'll ever make it trivial, but there may be a few
things that can be done to simplify it:

1. How about adding a flags field into the login command that describes
negotiations that are expected from the alternate.   Something like:

LOGIN FLAGS (example only)
-----------
CID Recovery Requested           	(FALSE = New CID Requested)
Custom configuration pending     	(FALSE = Current configuration
accepted)
Security Method Required            (FALSE = Security method defined)
Security Login Required             (FALSE = Authentication complete)
Target Not Yet Identified           (FALSE = Target identified)
Initiator Not Yet Identified        (FALSE = Initiator identified)
In Login					(FALSE = Full feature mode
accepted)

The login from I->T describes the options it requires from the target.  The
initiator may want to recover a previous session, set custom configuration
options, authenticate the target, etc.  Messages T->I may state requirements
for the initiator:  authentication, identification, etc.

Login messages can be exchanged until all requirements have been met.  When
both initiator and target have satisfied their login requirements, a
login/login response is issued with a completed status.  By setting
requirement bits in the requests/responses, the sequence of login events can
be orchestrated.



2. Do we really want to use TEXT= based messages for sending and receiving
configuration and authentication requests?  One of the things I'm concerned
about is the use of English (or English acronym) to provide the parse keys
for the transactions.  Can we use something a little more international?

The spec already describes mode pages for iSCSI.  Mode pages are easily
translated to other languages and avoids parsing problems (LoWeR CaSe
translation, decimal/hexadecimal translation, etc.)  Perhaps extending mode
pages into variable and login negotiations would be useful.  However, rather
than creating a bunch of different mode pages, we can limit it to just a
few:

Parameter negotiation page

+--------+--------+--------+--------+
| PageID |    Variable page length  |
+-----------------------------------+
| Variable Identification           |
+-----------------------------------+
| Number of array elements          |
+-----------------------------------+
| Value(s)                          |
.                                   .
.                                   .
+-----------------------------------+

Page lengths are word aligned.  Null pad bytes are used to extend lengths to
even words.

Variable Identification

1=MarkerType
2=TargetName
3=MaxConnections
4=TargetAddress
5=...

Security page

+--------+--------+--------+--------+
| Sec-Pg |    Security page length  |
+-----------------------------------+
| Value                             |
.                                   .
.                                   .
+-----------------------------------+

PageID
0=Respond with the current value of this variable.
1=Respond with array of known/possible values for this variable.
2=Set and respond with the default value for this variable.
3=Request this variable take on this new value.  Respond with actual value.
4=Request the alternate select from a value listed.  The response will be as
a '3'=set request.
5=Security question phase page
6=Security answer phase page
..

Variables or requests not understood are responded with a zero element page
with a zero value length.

Multiple pages can be attached to the login request/response messages as
needed.  The Login Request & Login Response messages are used at all times
throughout the login negotiation process.