|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: SendTargets in login or FFP?
Julian:
In order to try to organize information about the key parameters,
I developed the attached ASCII text file which characterizes each
key from draft 7 according to 4 attributes:
1. what type of key it is, which determines in which login phase
it can be used.
2. when the key can be negotiated.
3. who can send the key.
4. the scope of application of the key's information.
The values of these attributes were drawn from Appendixes A and D.
The only new information added (i.e., information not in draft 7)
is the characterization of keys into 3 types - security, operational,
and informational, where the new category "informational"
applies to keys, such as TargetAddress, TargetName, InitiatorName,
etc. which can be sent in either the security or operational
subphases of login, and which simply provide information rather
than negotiate values.
There is still a question with regard to the SendTargets key
-- many of the recent postings regarding the use of SendTargets for
discovery sessions indicates that people expect this key to be used
only in Full Feature Phase. Quoting from Mark Bakke's e-mail of
24-July:
> "Anyway, SendTargets is always done in full feature phase, and
> never during the login phase."
and later in the same message:
> No. The point of doing SendTarget in full feature phase is that the
> initiators must first go through their normal authentication;
> SendTargets responses will often be based on the initiator's identity.
Is this limitation correct? Or does this limitation apply only for
discovery sessions?
The draft currently characterizes SendTargets as ALL, which
does not imply this limitation.
If SendTargets is so limited, it would be the only key that could not
be used somewhere during login. To cover this case in the attached table
I have added the category FFP to the 3 existing categories IO, LO,
and ALL. Draft 7 would have to be modified to reflect this.
If this limitation is not correct, the category FPP
disappears and the ALL category would continue to apply to SendTargets
(and targest can expect to receive SendTargets during login).
Thanks,
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
On Tue, 24 Jul 2001, Julian Satran wrote:
> Eddy,
>
> SendTargets can be used in both discovery session and normal session.
> Would you please clarify when you think this restriction should apply?
>
> Julo
>
> "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
>
> Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
>
> To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject: iSCSI: SendTargets in login or FFP?
>
>
>
>
> The spec says:
>
> An initiator can log into this default target [iSCSI]
> name, and use a command called "SendTargets" to retrieve a list of
> iSCSI targets that exist at that address
>
> I assume this means the SendTargets would be used in Full Feature Phase ...
> the initiator would login using TargetName=iSCSI. That would get into FFP
> and then the initiator would use SendTargets= to get the list of targets.
> Then, login again with the appropriate target.
>
> The spec says:
>
> In full feature phase the initiator may send SCSI
> commands and data to the various LUs on the target by wrapping them
> in iSCSI PDUs that go over the established iSCSI session.
>
> That means the target has to do something if a CDB is received to the iSCSI
> canonical target. The spec doesn't give any suggestions here. I am assuming
> the target would give a reject PDU with a reason of "Protocol Error" (code
> 5).
>
> Do you agree that this is what should happen?
>
> We shouldn't require that the target enter FFP when it would not be valid
> to
> send a CDB. I think SendTargets should be done only at LO or IO time and
> that iSCSI should not get you into FFP. That would simplify coding.
>
>
> Eddy_Quicksall@iVivity.com
>
>
>
>
There are 4 attributes or properties that characterize each key:
1. The type of key, which determines in which login phase it can be used:
a. security - security phase only - Appendix A - my label SEC
b. operational - operational phase only - Appendix D - my label OP
c. informational - both phases - Appendix D - my label INFO
2. When the key can be negotiated:
a. during the leading login that establishes a new session - label LO
b. during any login - label IO
c. during any login or during full feature phase - label ALL
d. during full feature phase only - my label FFP
3. Who can send the key:
a. Initiator only - my label I
b. Target only - my label T
c. Initiator and Target - IT
4. The scope of application of the key's information:
a. Session specific - session-wide - my label SESS
b. Connection specific - particular connection only - my label CONN
c. Not relevant - my label NR
The keys defined in Draft 07 Appendixes A and D (with section and page numbers):
Att1 Att2 Att3 Att4
No Key Page Type When Who Scope
-- --- ---- ---- ---- ---- -----
01 HeaderDigest 135 SEC IO IT CONN
01 DataDigest 135 SEC IO IT CONN
01 AuthMethod 135 SEC IO IT CONN
10 MaxConnections 157 OP LO IT SESS
11 SendTargets 157 INFO FFP I NR
12 TargetAddress 157 INFO ALL T NR
13 TargetName 158 INFO LO I NR
ALL T
14 InitiatorName 159 INFO LO I NR
15 TargetAlias 159 INFO ALL T NR
16 InitiatorAlias 159 INFO ALL I NR
18 AccessID 160 INFO ALL I NR
19 FMarker 161 SEC LO IT CONN
20 RFMarkInt 161 SEC LO IT CONN
21 SFMarkInt 162 SEC LO IT CONN
22 InitialR2T 162 OP ALL IT SESS
23 BidiInitialR2T 162 OP ALL IT SESS
24 ImmediateData 163 OP LO IT SESS
25 DataPDULength 164 OP LO IT SESS
26 FirstBurstSize 164 OP LO IT SESS
27 LogoutLoginMinTime 165 OP LO IT SESS
28 LogoutLoginMaxTime 165 OP LO IT SESS
29 MaxOutstandingR2T 165 OP LO IT SESS
30 DataOrder 165 OP LO IT SESS
31 DataDeliveryOrder 166 OP LO IT SESS
32 CommandReplaySupport 166 OP LO IT SESS
33 CommandFailoverSupport 167 OP LO IT SESS
34 SessionType 167 INFO LO I SESS
35 OpParmReset 167 OP IO IT CONN
36 X--- 168 OP ALL IT ?
Home Last updated: Tue Sep 04 01:04:07 2001 6315 messages in chronological order |