Re: iscsi : target port definition

[Santosh Rao <santoshr@cup.hp.com>]

Jim,

I agree with your below ideas. However, they do appear to conflict with the
iscsi rev 08 definition of the I-T nexus in Section 1.5.2 which reads :

" c) I_T nexus - According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a  SCSI Target Port.  For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session  (SCSI Initiator Port) and the iSCSI Target's Portal Group.  The
I_T nexus can  be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI
Initiator Name + 'i'+ ISID, iSCSI Target Name + 't'+ Portal Group Tag).

NOTE: The I_T nexus identifier is not equal to the session identifier (SSID).
"

Per the above definition, the I-T nexus target end point is that target portal
group, which is not the case when initiators choose to establish I-T nexi
(sessions) to subsets of the target portal group, in order to export multiple
scsi paths to upper layer wedge drivers.

Further, initiators that establish sessions to a subset of the target portal
group would not be able to take advantage of initiator specific mode page
implementations on the target. All the I-T nexi (sessions) established by
seperate initiator ports to a given target portal group would always share the
same mode pages, since the target mode pages would be implemented on a per
target portal group basis.

Do you see any reasons why the definition of a target port should not be
symmetric with the definition of the initiator port ? i.e. (iscsi target name
+ TSID) = target port. (= both port name & port identifier). This would more
accurately model the target port to be the end point of the I-T nexus
(session).

Regards,
Santosh


Jim Hafner wrote:

> Santosh,
>
> There are many alternatives here, but I think the simplest is to establish
> multiple sessions to the one target portal group.  Each session can connect
> to one, some or all of the target ipaddresses in the portal group, so you
> have a lot of flexibility.  What you see then in the wedge driver is
> multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target
> Port.  That should be sufficient for the multipathing logic.    So, it's
> many to one, not one to many.
>
> Note that according to the model in -08, if there were more than one target
> portal group, you could see two different things, depending on how you
> implemented your host.  You could have an "implementation" of one host SCSI
> Initiator Port connecting to multiple SCSI Target Ports if you used the
> same ISID for all those sessions.  Or you could have an implementation of
> multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple
> SCSI Target Ports if you used a set of ISIDs.  In other words, the reuse of
> an ISID to a different target portal group implies a one to many setup.
> And you can overlay lots of one-to-many (or one-to-one) sessions as you
> enable different ISIDs.  In other words, the "many" SCSI Initator Ports are
> based on multiple use of ISIDs and multiple SCSI Target Ports are based on
> multiple target portal groups as advertised by the target.
>
> On the other hand, there is no requirement of the target that if advertise
> itself as having only one target portal group, even if it was capable.  It
> can subdivide its ipaddress space in any way it wants.   A high end target
> with many many ip interfaces will probably do that.  Additionally, any
> truly high end target (in the long term) will have many iSCSI HBAs (most
> likely) each functioning as a target portal group and you'd see this
> modeling FC (at the target side) closer.
>
> There might be other reasons besides multiple iSCSI HBA configuration for
> the target to advertise multiple target portal groups. The SCSI Asymmetric
> Port behavior for controllers in particular (for failover, primary pathing,
> etc.) can take advantage of that kind of structure.  You may have a
> dual-headed controller each with independent power supplies.  They might
> have enough coordination to run sessions across all of them, but it might
> make more sense to separate them.  [Give me more time and I can probably
> come up with lots of other reasons too...]
>
> The model then is flexible enough to handle arbitrary software
> implementations using arbitrary network or TCP hardware cards as well as
> any implementations of iSCSI HBAs or any combination of the two. And that's
> true on both the initiator and the target side.
>
> Jim Hafner
>
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 09/13/2001 05:37:45 pm
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   IPS Reflector <ips@ece.cmu.edu>
> cc:
> Subject:  iscsi : target port definition
>
> Hello,
>
> I have a question on the interpretation of the iscsi target port
> definition. The iscsi rev 08 defines the iscsi target port to map to an
> iscsi target portal group.
>
> Thus, any iscsi target that wishes to allow multiple SCSI paths to be
> established to the target node MUST provide at least 2 iscsi target
> portal groups.
>
> The above definition of an iscsi target port somewhat alters the
> semantics of a target portal group. A target portal group, by
> definition, is a collection of a set of network portals within the
> target across which a session can be spanned.
>
> Thus, if a target supports a multi-connection session spanning across
> all its network portals, such a target would use a single target portal
> group to indicate that 1 big fat session pipe could be established to
> all its network portals. This, in turn, would have the side effect of
> only providing 1 scsi path to the upper layer wedge drivers, if the
> iscsi initiators establish a session per target portal group. [which is
> the target port].
>
> >From an initiator's perspective, what should be the target side
> end-point of an initiator's sessions when it may need to support upper
> layer wedge drivers ? Should the initiator establish a session per
> target
> portal group [, in which case the above issue exists] ? Or, should it
> establish a session per TargetAddress ??
>
> Regards,
> Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard