Subject: iscsi : changes involving tgt portal group tag.

From: Santosh Rao <[email-masked]>
Date: Fri, 01 Mar 2002 18:02:54 -0800

All,

I believe iscsi needs to make 2 changes :

1) to mandate persistence of the portal group tag (and thus, persistence
of its scsi target port identifier). 

2) to send the portal group tag (scsi target port identifier) as a part
of the iscsi login request.

The rationale for (1) is :
--------------------------
SAM-2 requires scsi port names to be persistent and world-wide-unique.
(SAM-2 Rev 22 Section 4.7.7). Quoting from SAM-2 :

"A scsi port name shall never change and may be used to persistently
identify a scsi initiator port or target port...".

iscsi defines scsi target port name as :

iscsi target name + NULL delimiter + 't' + NULL	+ (0 - 3) bytes of NULL
padding + 2 byte portal group tag (in big endian format).

In order for the above scsi target port name to meet SAM-2's requirement
of being persistent, the portal group tag needs to be persistent.

The rationale for (2) is :
--------------------------
Consider an initiator node establishing multiple sessions to a scsi tgt
port, with each session established to a subset of the network portals
within the tgt portal group. 

Consider an iscsi transport event involving the re-configuration of
target portal groups on the iscsi target node. This may be preceeded by
the iscsi sessions seeing an async message "target requests logout",
followed by session logout, portal group re-configuration, and then, the
initiator re-establishes sessions.

Across a transport event that results in such session termination and
re-establishment, the initiator needs to authenticate that it is still
speaking to the same [i]scsi target port, in order to ensure that any
open/active I-T-L nexus traffic on that session is not incorrectly
routed to a wrong LUN after such a transport event.

Note that the session end-points in such sessions  are individual
network portals within a portal group (tgt port) and a target
re-configuration involving the moving of network portals from 1 portal
group to another can occur.

Following such a re-configuration, if an initiator were to re-establish
a session to the same session end-points, since there is no addressing
information carried in the iscsi login request which carries the target
port identifier, the session may be established to the same network
portal, but under a different scsi target port and the I-T-L nexus
traffic incorrectly routed to a different scsi tgt port, resulting in
potential data corruption.

Other session oriented SCSI transports like FCP and SRP address this
problem by defining authentication schemes as well and/or explicitly
carrying the target port identifier in their login requests, which allow
them to identify such an authentication mis-match.

To prevent such authentication issues, iscsi can send the iscsi target
port identifier (portal group tag) explicitly in the login request, and
the login can be rejected by the target on a portal group tag mis-match.
(if the network portal does not belong to the addressed portal group
tag).

Also, on any portal group re-configuration, iscsi targets MUST terminate
the session to avoid such scenarios as described above.

Comments ?

Regards,
Santosh

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: Paul Koning <[email-masked]>
Date: Tue, 12 Mar 2002 14:50:44 -0500

Apologies for the late followup, but this discussion has me puzzled.

Part of the concern appears to be around the worry that an initiator
might reconnect to "the wrong" port and as a result end up talking to
the wrong LU when it issues additional commands to a LUN it knows.

I don't understand how that's possible.  SAM-2 section 4.7.3 shows
that an LU is a component of a Device (not of a Port).  And 4.8 says
that a LUN "identifies the logical unit within a SCSI target device".

In other words, no matter what port you use to access a device, a
given LUN identifies the same LU in that device.

As for the rule in SAM-2 section 4.7.7 that a "port name shall never
change" and the conclusion that therefore a TPGT must be persistent, I
would ask "across what scope?" and "how would you tell"?

If I have an iSCSI device that at time T has a port named X, and at
time T+1 has a port named Y, how would I test whether the proposed
requirement has been implemented?  I think the answer is: if you can
see state you created, such as reservation state, but it's now
attached to a different port name, then that requirement has been
violated.  Conversely, whenever a target port has no state it needs to
remember (no reservations, no initiator-specific mode pages (iSCSI
section 2.4.3.1)) then it can disappear and a new target port can
appear in its place -- or equivalently, the port can simply change
its name, you can't tell the difference.

I guess what I'm getting at is this: a requirement for something to be
persistent has meaning only if there's state attached to that
persistent thing, state that you can observe.  What exactly is that
state and long must it be kept?  iSCSI 2.4.3.1 lists some (but it says
"e.g." so there might be other state?).  Without a complete list of
that state it's hard to figure out what the correct rule should be.

       paul

---

From: Martins Krikis <[email-masked]>
Date: Tue, 12 Mar 2002 13:43:03 -0800 (PST)

Dear list members,

This must be a stupid question, but I can't find the
intial values of CmdSN and StatSN specified in
draft 11. I only see a requirement to start DataSN
at 0.

Are CmdSN and StatSN also supposed to start with 0,
or is the starting value completely arbitrary?

(I followed an old discussion about CmdSN, but this
issue is still unclear to me.)

Any help is much appreciated.

  Martins Krikis, Intel Corp.

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

---

From: Martins Krikis <[email-masked]>
Date: Tue, 12 Mar 2002 15:37:05 -0800 (PST)

Dear list members,

I've just noticed that ExpDataSN is used to denote
a lot of different things (all references w.r.t.
to draft 11):

1) the total number of Data-In PDUs that a target
   has sent to complete a SCSI (read-like) command
   (2.5.1.2, 9.4.7, 6.6, E.9.2);

2) next concecutive input DataSN number expected by
   the initiator for the referenced command in
previous
   execution, used in TASK REASSIGN
   (6.1.2, 9.5.4);

3) internal target variable used to track the next
   DataSN Expected from the initator or something
   like that
   (6.2).

Regarding use 1: this is the most widespread, and
there is nothing to object, except perhaps that the
name ExpDataSN doesn't convey the exact meaning---
"TotalDataPDUs" or "NumDataPDUs" or something like
that. Anyway, I can live with this.

Regarding use 2: the name conveys the meaning, but
I don't like the wording of this spot in 6.1.2:
"... for example taking advantage of ExpDataSN in 
the iSCSI command PDU for read commands...". The
problem is that "read commands" don't have ExpDataSN
in the PDU, it's the "Task Management Function
Request"
PDUs that do. Task Management Function Request PDUs
are, of course, "iSCSI command PDUs", but the whole
thing makes it too easy to make the mistake of
remembering (the ill-named) ExpDataSN field in 
SCSI Response PDU, at which point nothing makes sense
anymore, because that's the other meaning of
ExpDataSN.
I would appreciate if somebody could rephrase the
sentence. I'll even volunteer:

"In reassigning connection allegiance for a command,
the targets SHOULD continue the command from its
current state. For example, when reassigning read
commands, the targets SHOULD take advantage of the
ExpDataSN field provided by the Task Management
Function Request PDU (which must be set to zero
if there was no data transfer) and bring the command
to completion by sending (or resending) the status."

Regarding use 3: I don't understand this. The last
two sentences of 6.2 seem to be talking about
Data-Out PDUs, therefore uses 1 and 2 of ExpDataSN
(that are both Data-In PDU related) don't apply
here. I'm concluding that these sentences are 
making some (unwelcome) assumptions about target
implementation details (e.g., ExpDataSN in the role
of a variable used to track the DataSN of the next
Data-Out PDU that a target expects to receive for
this command). If so, I would like such assumptions
dropped and no MUSTs (and MAYs) imposed on a target
implementation. If I'm wrong, somebody please explain
to me what was meant here.

"Bonus" :-) problem:

While we're at 6.1.2, the start of the 3rd paragraph
also got me thinking and browsing the draft for 
quite a while. I don't like the "This is true even
when the CmdSN can be reliably ascertained..."
phrase. The problem is, I don't see how it could not
be reliably determined for rejected PDUs. My thinking
is that the only way to not be able to reliably
determine CmdSN is in the case of header digest
errors.
But in this case, the PDU must be silently dropped,
and not be answered with a Reject PDU. Am I wrong
somewhere? If not, can we change the sentence I
mentioned to something that explains that for rejected
PDUs, the target will necessarily have a good CmdSN,
but still must not use it"? 

Help on these issues will be much appreciated.

Disclaimer: These opinions are mine only and
            may not reflect those of my employer.

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 18 Mar 2002 14:34:04 -0800

Martins,

Sorry for the delay in getting to this...

ExpDataSN always means the expected DataSN from some entity's
perspective in some scope.  It may (as in reassign TMF), or may not
(as in write data reception) be communicated to the other entity.  I do
not consider the ExpDataSN for write data as an implementation issue,
iSCSI defines the error recovery protocol  if the ExpDataSN is not 
received.

Regarding 6.1.2, I agree that the wording can be improved - and your
suggestion is a good fit.

Regarding the last two sentences of 6.2:  the text is referring to the 
ExpDataSN of the current burst in a Data-Out sequence.

Regarding the "even when the CmdSN can be ...." wording, you are right - 
I will modify the sentence to imply what you suggested.

Thanks!
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]