|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: TSIH clarificationsI don't see any problems with the current descriptions of TSID/TSIH :-). It has been noted earlier by Julian on IPS that TSID is rather redundant as uniqueness is achieved by INAME+ISID+TPGT+TNAME. (Mar 17 2002, Subject: TSID rule.) From this you can derive simpler tuples if you implement just a single TPGT. See another thread on ISID rule in which there is a table describing ISID TSID CID combinations and their actions. Maybe Julian will insert it into the iSCSI text as it will make things a lot clearer. Further comments in inlined: "Martin, Nick" wrote: > > Julian, > > Some comments/questions about TSIH > > Draft 11-94 text: > > 9.12.6 TSIH > > TSIH MUST be valid only in the final response. The target is gener- > ates and uses it and its internal format and content are not defined > by this protocol except for the value 0 that is reserved and used by > the initiator to indicate a new session. It is given to the target, > during additional connection establishment for the same session, to > identify the associated session for the target. > > The above paragraph is under Login Request. (The word "is" in the second > sentence should be removed.) However it seems to describe the field more > from the Login Response point of view. Here is some alternate text to > instruct the initiator constructing the Login Request PDU, and the target > interpreting it. > > 9.12.6 TSIH > > TSIH must be set in the first Login Request. The reserved value 0 > MUST be used on the first connection for a new session. Otherwise > the TSIH sent by the target at the conclusion of successful login of > the first connection for this session MUST be used. The TSIH > identifies to the target, the associated existing session for this > new connection. The target will verify that a session with this TSIH > exists, and that all other session identifying parameters of this > connection also match that session. This is confusing. If you are going to use ``must'' please use ``MUST'' or don't use it at all, as this is a protocol document. The 3rd sentence is sematically backwards. The 4th sentence uses ``this connection'' -- there is no connection in context to be referred to as ``this''. You over-simplify things in your last sentence. > All Login requests within the Login phase MUST carry the same TSIH. See below. > The target MUST use the value presented with the first login request. > > Draft 11-94 text: > > 9.13.3 TSIH > > The TSIH is the target assigned component of the session identifier > (SSID). TSIH MUST be valid only in the final response. The target is > generating and using it and its internal format and content are not > defined by this protocol except for the value 0 that is reserved and > used by the initiator to indicate a new session. It is given to the > target, during additional connection establishment for the same ses- > sion, to identify the associated session for the target. > > The above paragraph is under Login Response. My question is regarding > the sentence "TSIH MUST be valid only in the final response.". This could > be read to mean that the TSIH, if known by the target at some earlier point, > must not be supplied to the initiator in any non-final login response. > Was it intended to mean this for some security reason? Or does it mean only > that the initiator must not use the value until the final login response. The target is passive, it doesn't guess, but scrutinizes its input from the initiator during the login stage and is ``trigger-happy'' to close the connection. Unless the initiator provides TSID/TSIH at the first login request, for the purpose of ... (read the draft), then the target will scrutinize all traffic, data, connection source, etc, and will close the connection or _generate_ the TSID/TSIH on the last response of a stage transition sequence to FF. Similarly to how PIDs are generated in OSs. > Which of the following best represents the intent of that sentence? > A) "TSIH only MUST be valid in the final response." > B) "TSIH MUST be valid in the final response. Otherwise it is reserved." > C) "TSIH MUST be valid in the final response. Otherwise it MUST be 0." Given the RIGHT circumstances (i.e. new session): A) since the drafts specifies it, B) since the initiator shouldn't touch it until the last response to a stage switch to FF. C) Since the draft specified in the beginning that anything not explicitly set should be set to 0. See, they are all correct given the right circumstance (new session). You need to know the context you're at. > The above primarily applies to the leading connection of a new session. > In the case of a connection other than the first in a session, > the TSIH was supplied by the initiator in the first (and every) > Login Request for this connection, should this value not be copied into every > login response? Since you are mentioning ``response'' I'd assume that you are talking about the target: blind copying is a dangerous business -- the target should scrutinize the value and close the connection if necessary. (see the table in a post by Mallikarjun re ISID rule thread) -- Luben
Home Last updated: Fri Apr 12 21:18:20 2002 9646 messages in chronological order |